List of FPGA cores that could be ported to Chameleon hardware

Caution: Non registered users only see threads and messages in the currently selected language, which is determined by their browser Please create an account and log in to see all content by default. This is a limitation of the forum software.
  • Would love to see a 486 core. Could the ao486 MISTer core be ported over for the Chameleon?

    No chance at all, I'm afraid - the ao486 CPU alone needs about 35,000 LEs, without BIOS, video, sound, IO, SDRAM controller, etc. The Chameleon has about 25,000.


    As far as PC cores go, I do plan to have a play with the Next186 core at some point.

  • as said before, the next186 core is already ported (only to v2 though). unfortunately its a bit fiddly to use (and the author doesnt seem to be interested in adding loading the rom from flash)

  • as said before, the next186 core is already ported (only to v2 though). unfortunately its a bit fiddly to use (and the author doesnt seem to be interested in adding loading the rom from flash)

    I downloaded it tonight, and verified that the source is complete enough to build (which it is), so backporting to V1 should be easy enough. I haven't yet tried it out, or tried preparing an SD card, though.

  • it worked quite nice for me.... plays wolfenstein and stargoose and commander keen etc :)


    setting up the SD card is a bit fiddly though, as said... it would be really great if you could make it use the flash instead :)

  • as said before, the next186 core is already ported (only to v2 though). unfortunately its a bit fiddly to use (and the author doesnt seem to be interested in adding loading the rom from flash)

    Sorry, did not see that. Will have to take a look now.

  • (and the author doesnt seem to be interested in adding loading the rom from flash)

    I can see why the author would be reluctant to add hardware to the PC's IO map and modify the bootloader specifically for one target platform. The bootloader reverts to RS232 if SD boot fails, though - so the least invasive method would probably be some kind of flash -> RS232 bridge.

  • His proposal was writing a flash loader for the bootloader.... my intel asm is more than rusty though, i cant even read the bootloader properly anymore, so i scrapped that idea :)

    Yeah, that's the obvious solution - it would need a way of exposing both the Flash chip and the µC's usart to the PC, though. Then rewriting the bootloader and hoping the result is still small enough. (There's no ROM - the bootloader works by seeding the CPU cache with data, marked as dirty so it's written back to RAM as soon as the cache line's needed for anything else. Which is genius, but also leaves me loath to touch it! Plus I've never explored x86 asm.)


    I'm tempted to just brute-force it and add a control module similar to the OCMSX, PCE, etc. Then the BIOS can be loaded directly from the filesystem - plus that solution's applicable to other target platforms, too.)


    in different news, someone passed this link to me: https://github.com/pgate1/SNES_on_FPGA - no idea how useful it is or how realistic a port to chameleon could be :)

    Oh wow! I've just downloaded it but it's pretty much all written in SFL+, not a language I've encountered before, and not one Quartus supports. The development blog (in Japanese) mentions an sfltovl utility that I haven't yet managed to track down.

  • His proposal was writing a flash loader for the bootloader.... my intel asm is more than rusty though, i cant even read the bootloader properly anymore, so i scrapped that idea :)

    I've been exploring Next186 a bit more over the last few weeks, and learned the following:

    • Writing the BIOS to the end of the SD card is a pain.
    • Reading the size of a non-HC SD card is a pain.
    • Because of this, the existing Next186 Bootloader & BIOS only support SDHC cards.
    • FreeDOS has several different bootloaders and the FAT32 one requires a 386 CPU so Next186 can't boot from a FAT32 FreeDOS partition, meaning SD cards larger than 504mb have to be partitioned. This, again, is a pain. (I haven't yet explored MS-DOS - this problem might go away with MS-DOS, I don't yet know.)
    • To boot from SD card we need some way to install the bootloader, which means virtualbox, bochs, qemu or suchlike. Persuading Virtualbox to access a raw SD card is a pain.

    Over the last few weeks I've picked up enough x86 assembly to make some changes to the bootloader and BIOS, and spent some time adding my usual ZPU-based control module to the project. The bootloader and BIOS now talk to this rather than to the SD card directly, which means:

    • The BIOS can now be loaded from a file on the SD card.
    • Regular SD cards are now supported as well as SDHC.
    • It's also now possible to boot from a floppy disk image, sidestepping the inability to boot FreeDOS from FAT32. (It's also possible to use a floppy disk image to partition the SD card or install the bootloader, though of course the image goes away as soon as any changes are made to the partition structure.)

    I have the project mostly working on both V1 and V2 hardware - for some strange reason the OPL3 sound doesn't yet work on V1 (no music in Wolf3D - but sound effects do work) - once I've found and fixed that issue, I'll make binaries available for testing.