Replies

Yeah, that's exactly the issue I was (and still am) experiencing. I've ordered a bunch of old 2GB SD Micro cards on eBay which is probably going to help solving the issue on my end. I'll let you know in approx. a week whether that did the trick.

Hmm, so much for looking forward to getting things fixed with just a proper SD ;)

As far as I've read you don't need the CHARROM.G65 as a replacement character set is installed as part of the binary distro (the .bin file).

That leaves the C65GS.ROM. Yeah, I got a series of rom files from the same url as specified in your e-mail. You're saying you tested all of them? A convenient way to test all of them kind of at once is by having C65GS1.ROM, C65GS2.ROM and so forth and booting while holding down corresponding numeric keys on your USB keyboard. At least, that's what I've read and would try myself once I have a proper SD card.

the ROM checksum always is bad. 910111 is the one to go with, however other versions should boot aswell. For the charset, get a c64 one from zimmers.net and rename it. Try without a bootdisk at first, you can still mount it later. Please also make sure all switches on the board are set to OFF position. As you noticed, our SD implementation is not super clean yet so if you fiddle around, reformat (fat32) the card from time to time. Put the bitstream on it first, then the ROM, then the charset if you have one, then the bootlogo if you have one. Hope that helps - good luck and let me know!

The really important thing is that the partition table MUST be DOS-style FDISK (4 partition slots only), not EFS or one of the other newer disk layouts that allow more than 4 partitions. Please let us know if you succeed and someone please write a text tutorial ;)

Suddenly having problems with a 1GB sdcard again I just noticed a lot of bad stuff might or even will happen if you set the cluster size to default (4096 bytes) ! The C65 ROM kept dropping into debugger or not booting at all. Setting the cluster size to 512 bytes when formatting the card in Windows (fat32 of course) fixed the problem! I will try that fix for cards we thought to be incompatible (like 8GB and up) and report back.

Hi,
I'm also getting 'MOUNTED 00 PARTITIONS'. I've tried 1GB and 2GB cards that have been formatted as FAT32 with a 512-byte cluster size but had no success. I've formatted the cards on both Windows 10 and Mac OS X.

Clearly the card is accessible as the bitstream is loaded bit I have to assume there is something the hypervisor does not like about the partitioning of the card.

The hypervisor output is as follows:

GIT COMMIT: 53AFB2BE72AD392*
LOOKING FOR SDCARD…
FOUND AND RESET SDCARD
MOUNTED 00 PARTITIONS
COULD NOT CHDIR TO / (ERROR:00)
COULD NOT LOAD BOOTLOGO.M65 (ERROR:88)
NO KICKUP.M65 TO LOAD (OR BROKEN)
ERROR READING FROM SD CARD

The contents of the card are as follows:
BOOTLOGO.M65
C65GS.D81
C65GS.ROM
CHARROM.G65
ddr20150928.bit

I have problems with newest bitstream too.
1st: I renamed files to new name order, at boot no one except bitstream found
2. I added files in old name order and left on card both, found, unchanged ROM, old and new named same files - checksum incorrect, C65 mode works in MLM only, I mean broken Editor, C64 mode works ok
3. I left there all, only exchanged bitstream to old and:
Mega 65 works

The format of the SD card seemed to be the issue. I used DISKPART on Windows to create a 512MB partition on a 2GB card.
After doing this the hypervisor reported that 01 partitions were mounted :-)

However, it could not find the various files as I had named them incorrectly.
The setup guide I was using referred to C65GS etc whereas the latest release is expecting MEGA65. The file extensions have also changed from G65 to M65. Once the files were renamed everything booted fine.

Note that in addition to the bitstream file the other files need to be named as follows:
BOOTLOGO.M65
KICKUP.M65
MEGA65.D81
CHARROM.M65
MEGA65.ROM

Ok, only one file is mystery: KICKUP.M65
Which file it is in old filename order?
When I placed new bitstram with new filename order M65 was working not.
When I placed also filenames in old order M65 boots correctly only ROM checkum is problem and C65 mode works not correctly.
When I replace new bitstream to old, C65 mode works correctly - but why works not with new bitstream - ROM files are the same - only different names.

Apologies MIRKOSOFT, the file KICKUP.M65 file is not needed. I listed it in error as it is one of the files that is looked for as the system boots.

The only bitstream file I have is ddr20150928.bit so I have not tried any other combinations.
My SD card has the following files copied to it in the order listed below:
ddr20150928.bit
MEGA65.ROM
CHARROM.M65
BOOTLOGO.M65
MEGA65.D81

Older bitstreams require the additional files to have the extension G65 where the new ones are M65. Similarly the older files have the name C65GS where the newer ones are named MEGA65 etc.

I've been able to boot both the 910111 and 911001 ROMs from zimmers.net.

As noted, the KICKUP.M65 file is not required. It is for providing a patched Kickstart, without having to replace the bitstream. It is normally only required for people working on the kickstart code, or if we have a kickstart patch for you to try.

Note that to change kickup.m65, you have to first do a hard reset or physical power off, as it sets a write-once flag after loading kickup.m65, so that it doesn't sit in an infinite loop loading kickup.m65 over and over and over (and over).

Here is what worked for my setup: The SD card requires a primary partition to run from.

I have a 2GB Micro and a 4GB Micro SD card (non hc) and both worked perfectly fine once the partition on the card was set to primary. Originally it was "logical" and the latest bitstream failed every time. Once set to primary, cluster size while formatting was irrelevant--I used default and it worked fine.

Changing from logical to primary does not destroy the contents of the SD card--so if it's already setup, then changing from logical to primary is all you have to do. Using partition magic free edition (windows box), just right click on the micro SD and select change to primary. Then apply.

The order and the name of the files are the same as set out in reply #12.

An entire 2GB or 4GB (non HC) microSD card is bootable and usable--all the microSD cards that I have (about 12 of them from Kingston to the non-name cheap-O chinese knockoffs) work perfectly when set to primary.

Regarding the problems with the SD cards, it would be quite helpful if someone were to post me one of the SD cards that is not working, or if you prefer, on a UNIXy kind of OS, use dd to copy out the first 128MB of the SD card, zip it up, and email it to me.

I can then look at making the partition table code more robust. There is probably just a stupid bug in it somewhere.

As for whenever a ROM boots to the 80-column MLM monitor instead of C65 BASIC, this is a sign of a definite bug in the FAT file system code, where it incorrectly calculated the location of a cluster on the disk. We need to track down and fix this bug. If anyone would like to go through kickstart_dos.a65 and hunt for it, they will receive a smily face from me if they are successful.