Hallo Besucher, der Thread wurde 4,8k mal aufgerufen und enthält 21 Antworten

letzter Beitrag von Bloodypriest am

What systems is the Mega65 capable of?

  • Hi, I have been following the Mega65 project for a while and it looks really exciting. I would love to buy one when the become available but was thinking that with it being FPGA other cores could be possible. What realistically could the Mega65 do. Could it go up to an Amiga 1200, PS1, Dreamcast etc. Whilst I would use this as a C64/C65 if would be great to also use it For other systems. Also am I right the floppy drive wouldn't work for Amiga games as the disks were different to 1.44Mb floppies.

  • As far as the floppys go, I think HD drives are compatible with DD drives, the notches inside the disks tell the drive what kind of disk it is and thus how to read it.


    As far as systems go, in theory I'd assume that every system available for something like the MiST(er) should also be able to be ported over to the MEGA65, but it probably takes time and effort to do so. For example, the Ultimate64 board has been released in 2019, and as far as I know, there haven't been any other core ports so far. On the other hand, I heard someone say that the MiST's FPGA is bigger than the one in the Ultimate64.


    In a recent video, the MEGA65 team shows a Gameboy core running on the MEGA65.

  • Hi Drittz78 ,


    we have teammembers working on porting MiSter cores to the MEGA65. at the moment we have a fully working ZXuno core for the MEGA65

    as well as an, for the MEGA65 optimised, GBcore.

    So in principle all cores that work on the MiSTer will also work on the MEGA65 (but like ZeHa already mentioned, you need time to port them)

    To get an Amiga500+ working on the MEGA65 should be doable i think an Amiga 1200 is probably the max. limit.

  • I've been wondering about this yesterday. The MEGA65 will already be an awesome retro-computer being an updated recreation of the never released C65 but would the A200T have enough logic gates and memory to do something like the ao486 + extra bells & whistles to support the MEGA65-specific hardware like the ethernet port, real floppy support and HDMI output? From what I saw on OpenCores, ao486 uses less than 100000 logic gates so I think that should probably be doable. Serial could be joyport 1 combined with MousTeR and joyport 2 could be used to do gamepad port usually found on Sound Blaster cards. The version used in the MisTer improved slightly on the base design to allow for increased speed so it might be using a bit more than the original. Having both the original MEGA65 core and a secondary 486 core doing the real thing instead of emulation like DosBox in a secondary slot would make this the ultimate retro-computer.

  • The A200T is twice as powerful (logic gates) as the MiSTer FPGA.

    The A200T has internal 1MB RAM and ther are additional 8MB Hyper RAM integrated in the Mega65.

    Until now the software integration (driver) of the 8MB RAM is a bit slow, but fast enough for the Mega65.

    But is 9MB RAM sufficient for an 486 system?


    The MiSTer has a very big advantage to the Mega65 System.

    It contains a dual core 900MHz ARM CPU with 1GB RAM.

    On the MiSTer board (DE10 nano) is a preinstalled Linux System that is used for housekeeping duties. Specially the ao486 gets up to 256MB RAM, the whole IO-support (keyboard, mouse, gamepads, etc.) and more from the integrated Linux system.

    Also there is a very useful 32MB SRAM expansion for the MiSTer system.

    All MiSTer users own this RAM module. It is necessary to use all cores.


    I think all this disadvantages make it very difficult if not impossible to run the ao486 core on a Mega65.


    The Mega65 hardware has sufficient hardware (RAM) for simpler Amiga and Atari ST cores and all ancient 8 bit systems.

    I think we‘ll see some core ports from MiSTer, but no ao486.

    If you want MiSTer cores the easiest way is to buy a MiSTer.

    For 250-300€ you can have a complete MiSTer system

  • 4 MB is plenty enough by 1994 standards. And where's the fun in using something like the MisTer with an ARM CPU and a hidden Linux kernel inside? From my personal perspective, if I were designing a core, I wouldn't see the ARM as an advantage but as an invitation to being lazy and push everything to the ARM CPU and the Linux kernel since I know software development best.


    As for extra ram for the MEGA, there are two pMOD connectors available so an aftermarket REU isn't out of the question. Hmm, I'm giving myself ideas here.

  • From my personal perspective, if I were designing a core, I wouldn't see the ARM as an advantage but as an invitation to being lazy and push everything to the ARM CPU and the Linux kernel since I know software development best.

    Do you have any experience with developing such a "mixed-approach" system?

  • I never did vhdl and hardware design before but having the MEGA seems like a good occasion to learn. I'm a 3d programmer by trade so I deal more with load balancing between the CPU and the GPU. There's also making sure that the right mix of (the right kind of) ALUs and memory access are used because you don't want to make a different shader for each GPU that exist. That may or may not be mixed-approach to you but there's certainly a lazy way to do GPU programming and it's to go for maximum quality in FP32 without precomputing nothing in LUTs and recomputing static stuff every frame. Congrats, you now need a GTX3090 to run something that could run on a 970.

  • Just to throw this in as well:
    Pauls work on the MEGA65phone foresees a planed Raspberry PI to connect to the MEGA65 so a user could be able to run Android as well but controlled

    by the 4510.

    So iin principle you can hook up a Raspberry to the MEGA65.

  • 4 MB is plenty enough by 1994 standards.

    Here I fully agree. In the days of the 80486, most consumer PC came with 4MB RAM (and with all the "Real-Mode" nonsense still used in DOS, I guess that most DOS/VGA games were using only 640KB-1MB - not more).

    But if you wan't a authentic slow Win95/98 on 486 experience on FPGA, more RAM could help to have it usable at all.

    And where's the fun in using something like the MisTer with an ARM CPU and a hidden Linux kernel inside? From my personal perspective, if I were designing a core, I wouldn't see the ARM as an advantage but as an invitation to being lazy and push everything to the ARM CPU and the Linux kernel since I know software development best.

    MiST already has an ARM CPU (or MCU) with 48 MHz (no Linux), but it is not to do emulation of the replicated system, but more to select FPGA cores and translate modern I/O (USB HID devices, SD card) to something more similar to the HW interfaces of legacy devices of the day (keyboard matrix, DB9 mouse/joystick, floppy, etc).

    As the CPUs of the replicated systems often would not have enough compute power/RAM (or just an OS and driver concept) to do stuff like USB/FAT32-SD in software (and still be able to play games that are based on hardware banging), the only alternative would be to have another modern softcore CPU on the FPGA to do all this. Which would mean you need a bigger FPGA just to do stuff, that has enough ressources for an extra "I/O-computer" beside the replicated system.


    The Mister's Cyclone 5 comes with faster ARM-A9 "hard-cores" that are fast enough for an (embedded?) Linux, so the I/O devices don't need bare-metal software stacks but can be handled by Linux drivers, that are well tested and maintained and much more flexible. So it has not so much hassle with 'in-compatible' mouse, keyboard, game controllers, SD-cards compared to MiST (in it's early days).


    But the replicated systems cores are still more or less complete FPGA implementations - no CPU/FPGA hybrid emulations. The only experiment in this direction is a Minimig (Amiga) core that uses one of the MiSTer ARM CPUs to emulate an 680x0 ( so the TG68 softcore is removed/deactivated and FPGA is just doing the Amiga custom chipset). The idea is that an emulated and JIT compiled 680x0 on an 800 MHz ARM should be much faster (and may have FPU and MMU support) than the TG68 softcore (which is AFAIK a (non-pipelined) multicycle design running at around 100 MHz).


    I don't think that the hybrid approach is due to sloppyness. I guess it makes stuff more complicated but possible. One could argue that the Apollo 68080 and Vampire V4 shows that a much faster CPU - and FPU - is possible on FPGA. But the V4 has a much bigger (more expensive) version of the Cyclone V (but without ARM hard-cores). And it surely is way to complex to build and maintain for some open-source based hobby-projects like most of the Mister cores.

  • The MiSTer has a very big advantage to the Mega65 System.

    It contains a dual core 900MHz ARM CPU with 1GB RAM.

    Here comes my Q:

    We all know that it is possible to pre-order M65 only, even real production date for not so fast reacting buyers is I think far.

    I'm watching M65 project since 2013 where is was yet C65GS...

    Really it is 8 years away and I saw only devel machines and now pre-ordering.


    I don't want to wait, it can be very long time - small batches of production.

    I want to make choice to decide:

    buy MiSTer or M65... Mister gives me more platforms and M65 not yet.


    Is possible to run M65 core on MiSTer? Look at quote.

    No matter of porting - hardware requirements and I know possible incompatibilities to real HW.


    Thank you for explaining.

    Miro

  • Is possible to run M65 core on MiSTer? Look at quote.

    Short answer: No !
    Why ? The MEGA65 has a far bigger FPGA than the MiSTer. To rebuild a core the "attached" CPU doesn't matter at all, it's the number of how many logic cells you have available..
    Attaching an external CPU (like a Raspberry Pi) is possible with the MEGA65 as well. (It's not yet implemented, but it's possible.

  • Is possible to run M65 core on MiSTer? Look at quote.

    Short answer: No !
    Why ? The MEGA65 has a far bigger FPGA than the MiSTer. To rebuild a core the "attached" CPU doesn't matter at all, it's the number of how many logic cells you have available..
    Attaching an external CPU (like a Raspberry Pi) is possible with the MEGA65 as well. (It's not yet implemented, but it's possible.

    If the Mega65 would use more than 50% of its FPGA Artix-A7 200T, then you are right.

    But as far as I know the actual Mega65 core works on the NEXYS board and its FPGA Artix-A7 100T has only 101k logic elements.

    And the MiSTer FPGA Cyclone V on the DE10-nano board contains 110k logic elements.

    So the MiSTer should be able to run the Mega65 core.


    End of last year I started discussions in the MiSTer forum and the Mega65 forum.

    In the end Paul Gardner stated the he won‘t port the Mega65 core to the MiSTer platform, but would support a port.

    And the main MiSTer developer (sorgelig) stated that he‘ll have a look on the Mega65 core to port ist to MiSTer. But the Mega65 should finalised before starting any work.


    And I would like to know how much logic elements are used for the Mega65 from FPGA Artix-A7 200T (in percent).

    It should be less than 100k logic elements. Otherwise the core would be too big for the NEXYS board.


    Disussion inMega65 Forum:

    Porting the Mega65 project to MiSTer platform?

    Discission in MiSTerFPGA Forum:

    https://misterfpga.org/viewtopic.php?f=12&t=1473

  • I guess igel65 is right, although it is hard to compare system complexity just by percentage of used "logic elements" between different FPGA families.


    First of all, there is no standardized "logic element". The logic cells/slices of different FPGA can have very different design regarding LUT-size, imput/output flags and flipflops.

    So mapping your HDL/RTL to this cells is not straight forward and as of software compilers can also depend on how smart the synthesis tools can optimize for the actual HW.

    Next thing is routing: also the interconnects/fabric between the logic cells can be very different and making it more or less hard to place and route stuff.

    Then you may also depend on embedded RAM (block RAM) and it's layout and capabilities (dual-ported, LIFO, FIFO, etc) and on special function units like adders, multipliers, "DSPs", memory controllers, etc..

    And in the worst case some stuff is using hardware dependent "wizard" code - highly optimized for a particular FPGA architecture but not portable.

    Altera and Xilinx provide a lot of "libraries" and proprietary soft-core CPUs (NIOS2, MicroBlaze,...).


    But I guess that Mega65 is all more or less portable HDL without using vendor specific stuff.


    And from a practical point: this should still be a moderately complex 8-Bit design. It would be strange if Mister can handle much more complex 8/16-Bit and 16/32-Bit machines like SNES, Sega Genesis, NeoGeo, MinimigAGA/RTG, ao486, etc. but would not be capable of the a Mega65 core.


    How long did it take from the release of the ZX Spectrum Next (HDL source) until it was available on the Mister?

  • That might not be true forever as the MEGA65 is gaining more features and the core is getting more complex. Of course, one could skimp on porting the parts of the core that are used for interfacing with the floppy drive and cartridges as it's very unlikely the MisTer will ever have a cartridge port or a floppy drive with the exact same specs as the M65 Alps drive.

  • That might not be true forever as the MEGA65 is gaining more features and the core is getting more complex. Of course, one could skimp on porting the parts of the core that are used for interfacing with the floppy drive and cartridges as it's very unlikely the MisTer will ever have a cartridge port or a floppy drive with the exact same specs as the M65 Alps drive.

    Could happen, but it is very unlikely that the Mega65 will have so much feature creep soon, that it will fill up even the 100T logic cells of the dev board.

    It is much more likely that there a already a lot of Mister cores that are to heavy to port to the Mega65 - mostly because of it's limited external 8MB RAM.


    But however: first there needs to be someone willing and capable to port cores in one or the other direction. Before this happens, everything is just theory and speculation.