Another very quick post, just to say that we are now able to flash the MEGA65 bitstream into the flash on the FPGA boards. This means that from turning the power on, to seeing Kickstart takes only about 3.5 seconds -- and some of that delay is actually waiting for the monitor to turn on. If the monitor is already on, it can be quite close to 3 seconds, and possibly even a little less.
Power off to seeing C65 READY prompt, allowing time for the monitor to wake up from deep sleep took no more than 4.6 seconds.
This is very pleasing progress, and there is some scope for improvement. We are currently only driving the flash at 22MHz, which at 4 bits wide, and with a ~4MB bitstream. This means that loading the configuration currently takes (8*4x10^6) / 22x10^6*4 = 32x10^6 / 88x10^6 seconds = ~0.37 seconds, plus some overhead for the signaling between the FPGA and flash. I don't currently know the ratio of the overhead. In any case, it might be possible to shave another 0.1 second or so off the 0.37 second figure. Given that the total programming time on the FPGA at present is 1.7 seconds, this suggests that it might actually reduce the start time by more like 0.3 - 0.5 seconds. We will see.
The other thing we can do to improve boot time is to load the C65 ROM from flash instead of the SD card, or otherwise to reduce the SD card setup time.
I tried to find out exactly how long a real C64 takes to power on. My recollection is 1 - 2 seconds. It would be nice to match this, but I am already happy with < 5 seconds, compared to the about 15 seconds that it took loading the bitstream from the SD card. At some point I will post a video showing a MEGA65 booting from flash.
I am looking forward for the video :)
ReplyDelete1/2 seconds? There was no concept of "boot time" for typical 8-bit home computers of the '80s: you switched it on and a BASIC prompt was there ready, in less of a second I estimate.
ReplyDeleteYou are generally right, although the boot time of a regular C64 is still noticable: the borders pull in for some significant fraction of a second. Anyway, we will keep working on reducing the start-up time for the MEGA65.
DeletePaul
Paul sorry if my comment sounded a bit negative, it wasn't intended to be so.
DeleteNowadays every damn digital electronic product, besides PCs, has a boot time: TV sets, set-top boxes, stereo equipments, cell phones, ... I miss that instant-on feeling granted by the ability to immediately start to execute code from a ROM/(E)EPROM, without first copying it to RAM.
I'm really not up-to-date with current non-volatile memory technology: has it become so slow, compared to current processors speed, that such in-place code execution is out of question?
P.S.: some times ago I restarted my C64 after more than 20 years and unfortunately its internal RF modulator seems gone.
Hello,
DeleteThat's okay. We are basically booting the MEGA65 from ROM, but there is the necessary extra step of loading the configuration from flash into the FPGA. This should only take a fraction of a second. The main part of the boot delay is actually initialising the SD card, from where we load the C65's ROM, essentially for copyright reasons. In the future if we can get the appropriate permissions, we could include the C65 ROM in the FPGA configuration, which would allow us to potentially boot without waiting for the SD card, cutting the boot time down to the sub-1-second range.
Sorry to hear your RF modulator is dead.
Paul.
Hi Paul,
Deleteoh, of course... copyright problems. Note that when I mention a ROM I'm referring strictly to a chip (Read Only Memory) not to it's content (ROM image), basically the same role played by a flash chip nowadays (I clarify this to allow less expert readers to follow this conversation).
So, solved the copyright hindrance, in future it could be possible, while loading the FPGA configuration, to load also C65 ROM images directly into the 320 KiB of RAM that is inside the FPGA chip itself.
Correct? (I would liked to learn more about FPGA programming but never had the time or resources to study it.)
But back to the present, in an interview to Commodore Free (Vol. 9, Issue 88)¹ you mention a "MEGA-OS all-in-one hypervisor" (same on the mega65.org site): what happens if a card is not present into the SD card reader? Will this MEGA-OS take control and will offer a command prompt?
1. http://www.commodorefree.com/magazine/vol9/issue88.html#ARTICLE9
Proposal (note that I'm only asking if you like the idea, I'm NOT saying that YOU must implement it NOW): what do you think about adding a simple option (say: testing that a specific key is pressed) to MEGA-OS so that it can offer a command prompt immediately and proceed only to initialize the SD card reader in multitasking, without loading automatically any ROM image?
Anyway, I was looking about MEGA-OS into your C65GS GitHub repository but I didn't find anything, the same with a Google search. Is it somewhere else not indexed yet?
I see on mega65.org that an effort to develop MEGA-OS is planned: I think it's the right thing to do, the sooner the better. Because being C65 a prototype, there isn't much (if any) software developed for it and, until a near 100% compatibility with C64 will be available, I don't think that MEGA65 will arouse as much interest as it deserves.
Priced correctly it could be a good tool for learners, both for hobbyists that for students in various educational settings. Especially if the FPGA can be reprogrammed easily. If the flash memory is large enough, it could be possible² to do as in modern BIOSes, safely storing a backup copy of a known functioning FPGA configuration, available to load in case a re-flash operation fails.
2. A quick glance to "UG470 - 7 Series FPGAs Configuration User Guide", Chapter 7, "Reconfiguration and MultiBoot", p. 137, seems to indicate that this is possible indeed:
http://www.xilinx.com/support/documentation/user_guides/ug470_7Series_Config.pdf
If only bitstream formats were not proprietary it would be possible to develop a VHDL (or Verilog or whatever) compiler (no need for a PC to program the FPGA) so that MEGA65 would be an interesting Reconfigurable Computing³ (RC) platform (note to myself: search for up-to-date information about bitstream reverse engineering efforts).
3. See, for example: https://en.wikipedia.org/wiki/Reconfigurable_computing
Again, document above (UG470) seems to indicate that this is possible (see "Chapter 4, Dynamic Reconfiguration Port (DRP), p. 71"). Will your PCB design allow RC?
P.S.: do you prefer that I use the mailing list for this kind of conversations? I discovered your project only recently and I'm still slowly reading around about it.
Max
Paul I see that my last comment of two days ago disappeared, probably ingested by the anti-spam filter: it contains a couple of links, some questions and comments. If you have time check it, otherwise do not bother.
DeleteMax
Yes, Google's Spam Eater mistook it for lunch. It should be back there again now.
Delete