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.
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!
Keep up the good work!
ReplyDeleteI wish you the very best with this project. I can't wait for the day we can own this future brilliance.
ReplyDeleteJudge Drokk (Anarchy 1989-1993)
Awesome work dude.
ReplyDeleteGreat job!!!!
ReplyDeleteI've idly been wondering what it would be like to write games on this machine...
ReplyDeleteTBH I "hated" the BGAs in my previous work, maybe 15 years ago. It was such a "great" source of problems during warranty, naming few: delamination of pins when in hot environment + little PCB bending, "blackpad" issue (corrosion under soldering pins) and you need a special equipment to resolder them (which mad the blackpad issue came back even faster). combined with multilayer PCB and "via" problems, you had a great source of "fun time" during analysis, yeah. All these hiden or intermittet issues may take from you hours till identified.
ReplyDeleteI am eager to wake up the day I can click in "Add to chart" icon to buy this computer. Decades later, the history is completed.
ReplyDeleteHowever as a European, Commodores were not the most popular computer here. We were more into Spectrum, Amstrad CPC or even MSX. But computer enthusiast here appreciate about Commodores and their great potential. Commodores were like more difficult to get here in my area.
Since it is based in FPGA I wonder if it would be easy to configure it as an old Spectrun, Amstrad CPC, MSX, or even an old x86 to run old MS-DOS games or programs. I bet it would widen horizons to potential buyers.
Awesome!
ReplyDeletedo not deselect the hyperram there then it will respond to read request ;)
ReplyDeletewhen HyperRAMCSStrobe =>
if countdown = 3 then
-- Release CS line
hr_cs0 <= '1';
hr_cs1 <= '1';
end if;
I'll give it a try. I vaguely recall that the Hyperram has to have CS released sometimes to allow it to do refresh in the background, I think? But I could probably safely release it from CS in the Idle state, and then it should be fine.
Delete