Changing the drive number of the internal drives

A number of people have asked in the past how to change the drive numbers of the C65's internal 3.5" drive.  By default it sits on both device 8 and 9 (for the optional 2nd 3.5" drive via the little round PS/2 style plug on the C65).  Until now, I didn't know.  But Falk who is working on GEOS for the MEGA65 figured it out:

You just have to set the contents of $10113 and $10114 to the device numbers.  Note that these are 20-bit C65-style addresses, so you have to do some jiggery-pokery to swap them if you are in C64 mode on a C65, since there is no 20-bit monitor in C64 mode.

You can work around this by using the OPEN command to command the device number changes, e.g.:

However, if you are on a MEGA65, life is much simpler:  Long-press the RESTORE key to enter the Freeze Menu, and then press 8 to toggle the drive number of the first internal drive between 8 and 10, and 9 to toggle the second between 9 and 11, as you can see in these shots:

With this, you can easily have an external 1541 or similar on device 8, and do things like, say, load Sam's Journey:

Anton assures me that Sam's Journey is VERY smooth on the MEGA65.

Or better yet, see it in action:

Actually, one of the really great things about this post, is that all I did was a 5 minute fix to the Freeze Menu based on information that others had worked out, and the result was then tested by Anton.  That is, this is more of a post by the community and for the community, than it is a usual "what has Paul been making lately" post.  I hope that we see more and more of this kind of post, as the pre-series and then dev-kits and then retail versions of the MEGA65 get used more over time.

More Assembling of MEGA65 Pre-Series Machines

Just a quick post with some eye-candy of the growing number of fully assembled MEGA65 pre-series machines:

So much 8-bit fun in so little space!

Meanwhile, we continue to work to assemble the rest, and to figure out a good solution for financing the creation of the injection moulds for the cases for mass-production (the pre-series machines were produced using a very expensive per unit vacuum form process, that is much too expensive for mass production).

This is really the biggest remaining barrier. While we have some ideas we are exploring, now would be a great time for any wealthy sheiks in the audience to offer us their patronage ;) Or people willing to run sausage sizzles at their local home improvement stores, or whatever. We estimate the total cost of this stage to be around 65,000 €.  We'd naturally be happy to talk about appropriate ways to recognise any such support.

Of course this is the frustrating part where we need actual money, rather than being able to use volunteer labour. If I tried to calculate the value of the volunteer labour, I'd have to guess somewhere between 500K and 1M €, if we had to pay folks to have done the work.  This really is a labour of love on the part of many -- and from which we all benefit, since if we had to fund this project "properly" from the start, then (a) it probably wouldn't have happened; and (b) if it had happened, it would have had to have cut so many corners that it wouldn't be recognised. It is only through the voluntary efforts of so many that we have managed to re-create this lost unicorn of computers.

We really want to get this last hurdle settled before we move forward, because how we fund this is really the greatest uncertainty left in the process of determining what is a possible price, and thus to start moving towards being able to offer a pre-order mechanism for everyone who is longing to hold their very own MEGA65 in their hands.

MEGAphone rev2 PCB assembly work

While I have been flat out teaching, and thus lamenting the lack of time to work on the MEGA65, the same has not been true for my faithful students who have been doing great work on the MEGAphone. More specifically, on preparing the 2nd revision of the MEGAphone PCB to fix all the problems we found in the first revision.

The new PCBs arrived while I was in Germany at the CCC Camp.  But yesterday and today was time to by hand put all the surface-mount components onto the board and bake it in the oven to get all the components to solder down.

The following two shots show the board after they had been through the oven:

The hole-through components still need to be added, and we had only one of the LoRa radios on hand, so the other has been left vacant.

More news when we have put the hole-through components, and can start trying to bring the machine up.  Hopefully we won't need to do too many changes to the VHDL, as the boards are logically very similar.

Assembing the next few Pre-Series Machines

Keen MEGA65 watchers will know that the first two pre-series machines have already been assembled and are with me here in Australia.

However, all has not been quiet on the western front, with a couple of assembly nights, first to fit the missing pull-up resistors (this was while I was in Germany for the CCC Camp), and then again this week, to begin assembling several machines.  There will be similar gatherings each week until the remaining units have been assembled and our little packets of 8-bit perfection is ready to face the world.

We thought you might like to see a time-lapse of these first two evenings.  For the first one, we didn't have a proper camera handy, so we just put a phone on a convenient light-fitting, hence the slightly funny view from above.  You can also see my legs as I try to get some much needed sleep while waiting for FPGA synthesis to complete ;)

Then this week, the guys got together (sadly in my absence, as I am now back in Australia) and completed the assembly of the next four machines:

Last day of current MEGA65 development sprint

Okay, so today is the last day of the current MEGA65 sprint.  I am currently trying to get the following things working:

1. UUID serial EEPROM for MAC address etc
2. Real-Time Clock + onboard SRAM
3. Ethernet
4. HyperRAM

And currently having only limited luck with most of them.

The UUID EEPROM has 256 bytes of memory, the first 128 are writable, and the last 8 provide a globally unique identifier that can be used for generating a MAC address for ethernet. This was the easy one: Adapt the I2C peripheral code I wrote for the MEGAphone, and change the I2C addresses, and voila*, I was able to read it.

* Where voila actually means synthesising probably 3 or 4 times to track down all the little errors.

Then it's currently all a bit down-hill.

The real-time clock and its SRAM I have also mapped, and I can read and write the SRAM, which is great, and I can read and write MOST of the RTC registers, which is not so great. Specifically, I can do anything I like, except for set the clock.  Now, there is a register that controls this, and a WRTC bit that must be 1, before the registers can be written to.  And I know I can write to this device, because I can set the register with that bit, and I can even set the RTC alarm, and all sorts of other things -- but what I cannot get it to do, is to set the actual time.  The only clue I have found so far is in an example driver, which sets all 6 bytes at the same time.  So I might have to modify my code so that it does the same, to see if it helps.

Then we have the ethernet adapter.  Ethernet really shouldn't be a problem, as we have had it working in the past.  What I can confirm so far, is that the reset line works, because I can stop and start the ethernet, in so far as I can make the link LED go away, and then when I start it again, it reappears after a couple of seconds.  However, there is no hint whatsoever that the ethernet is actually transmitting or receiving anything to/from the FPGA.  Again, there really aren't any good places to probe with the oscilloscope, to see what is going on.  I'll have to keep thinking about it.

 

Then finally we have the 8MB HyperRAM that will be the expansion RAM of the MEGA65. The HyperRAM is not responding to read requests, and I am not yet sure why. I have switched to using a known-working open-source HyperRAM driver, and have it synthesising (which was a bit of an adventure due to a silly mistake on my part).  It is just timing out when reading, which could mean one of many things.  The chip is a little BGA, so I can't easily probe its pins to see what is happening.  So that's currently stuck.

So the current situation is quite frustrating. I guess I will start with trying to get the RTC working, and think about the others at the same time.

But, the day has got away from us, so these will have to wait until I am home in Australia, and have time to attack them.  But even with these little frustrating bits at the end, it is really pleasing just how much we have managed to achieve: the MEGA65 now runs on real hardware, and is super fun and pleasing to use.  We are currently making a series of short show-and-tell videos showing off the system, which can be found at:

https://www.youtube.com/playlist?list=PLPehmjqZolWDKTSE_cc_ft9jgYQyKZP_f

They are well worth the look, so hop on over and have a look!

Internal floppy drive now working on the R2 PCB, and various other bits and pieces

Oh my, it is already 11pm! So this will just be a short summary of what we have achieved today.

Most of the progress was getting the internal floppy drive working.  We had some more forgotten pull-up resistors that had to be added to the boards, and then to the schematic for the future R3 PCB.  So now you can happily use the MEGA65 CONFIGURE program, which works a bit like an old PC BIOS, to select the real disk drive or disk image to be used on power-up ... and it works!

We wrote a 1581 disk using a PC transfer program, and we can read it happily.  One funny thing we found, was that the drive refuses to read 720K data from a 1.44MB disk, even if the disk has tape over the HD hole.  We have no idea why this is, but for now it just means using real 720KB media.

Anyway, with the disk image, we are able to get a directory and load programs from the drive quite happily.  It could be my imagination, but I think it loads faster than my original C65 did. If so, it is probably due to our floppy controller perhaps being a bit faster.  Not sure. Not that important.  I did time loading a 161 block file, and it took 19.5 seconds, so about 8 blocks / second = ~2KB / second.  That does sound faster to me than the original, which I recall in C64 mode (which is how I ran this test just now) loaded at ~1.3 - 1.5 KB / sec. It could also be luck of the sector order on the disk, too.

Apart from that, we also updated the boot rom to set the audio mixer levels more sensibly, so now the SID audio that was super quiet is now quite loud.  We also fixed the audio channel control settings there, so that you can choose mono (both SIDs on both left and right channels), stereo, and stereo with swapped channels. At some point we will also add these (and the "use real floppy drive" to the freeze menu, so that you can easily change them at run-time.

IEC port testing / GEOS for the MEGA65 R2 PCB

Just a quick note to say that we got the IEC (1541 drive / printer) port on the MEGA65 R2 PCB working today as well.  This works well enough that we can even boot GEOS from a 1541 drive.

Of course, the native port of GEOS for the MEGA65 is much nicer, with higher resolution and MUCH faster booting: The GEOS load process takes probably less than 1 second.

We have yet to get C128/C65 fast serial working, but all the hardware is there for it.  We will come back to this when we have time. The priority for the next two days remains to test the remaining functions on the R2 board, so that Antti and the crew have confidence of any potential changes required for what will hopefully be the production-ready revision of the board.