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.
  • 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.

    Wow - that's a ton of work, and exactly the path we've discussed here. Should I say "great minds think alike" :-)?


    Does one of the many sound cards of the Next186 core have a MIDI interface? If so, the new Docking Station will come in handy.

  • Does one of the many sound cards of the Next186 core have a MIDI interface? If so, the new Docking Station will come in handy.


    Not yet, but I don't think there'd be much to adding dumb-mode MPU401 beyond sticking a 31250baud UART on port 330/331 and hooking up an interrupt.


    Adding support to the Minimig core should be simple, too - Bars and Pipes is still awesome!

  • Here's a pre-alpha release of the Next186 core

    http://retroramblings.net/snap…_Chameleon_2019-09-15.zip


    The zipfile contains binaries for both V1 and V2, along with a BIOS and an optional freedos boot image. The BIOS must be on the SD card (at least the one you boot with). You can boot directly from the SD card if you wish, but if you're using FreeDOS the first partition must be FAT16 formatted, because the FreeDOS FAT32 bootloader requires a 386 CPU. If the boot disk image is on the SD card then it can be FAT32 formatted; the boot code will come from the floppy disk image.


    Known problems:

    • There's no error handling or display of error messages for the disk image support or BIOS loading
    • The core sometimes comes up with a shifted or scrambled display. I don't yet know what's causing this, but I suspect it's to do with phase relationships between the core's multiple clocks, since resetting the core doesn't fix it.
    • The OPL3 emulation doesn't start properly on V1 hardware. I have no idea why this doesn't affect V2 hardware or the development Cyclone III board I've been using - the only thing V2 and the dev board have in common is that they have an off-chip 50MHz clock source, which is used by the OPL3, while the V1 hardware has to generate it in a PLL along with all the other clocks. I've tried many things to fix this, including adjusting the 50Mhz clock's speed and phase, synchronising, adding and removing reset signals - but the problem resolutely remains. As a workaround, I've mapped the Freeze button to a separate reset for the OPL3 emulator; pressing this usually causes it to spring into life.

    Source is at: https://github.com/robinsonb5/Next186_SoC

  • The BIOS must be on the SD card (at least the one you boot with).

    There is plenty of space in the flash slot of the Chameleon. Why not put the BIOS there? This would make the core work with any unprepared SD-card.

    As a workaround, I've mapped the Freeze button to a separate reset for the OPL3 emulator; pressing this usually causes it to spring into life.

    Please attempt to monitor the Lock signal from the PLL. While the PLL on the Cyclone 3 is way more stable than the Cyclone 10 (which is why we've added the 50MHz clock source), it may require it's startup time. Maybe a simple route from PLL-Lock to that reset input already makes it work?

  • There is plenty of space in the flash slot of the Chameleon. Why not put the BIOS there? This would make the core work with any unprepared SD-card.

    In the longer term that's certainly a possiblity - but I tend to try and avoid making a project specific to a particular platform if I can avoid it. I'm going to need to run the project on something with more blockram at some point because there's next to none left, making signaltapping difficult. Doing anything too Chameleon-specific at this stage makes that harder.


    It doesn't buy a great deal, either, since the SD card still either needs to be prepped using a virtual machine, or using a boot disk image - copying the BIOS file at the same time is no great chore. (Certainly much easier than writing it to the last 8K of the card!)

    Quote

    Please attempt to monitor the Lock signal from the PLL. While the PLL on the Cyclone 3 is way more stable than the Cyclone 10 (which is why we've added the 50MHz clock source), it may require it's startup time. Maybe a simple route from PLL-Lock to that reset input already makes it work?

    Yes, I'd considered the PLL-lock signal - though I didn't know the Cyclone 10 was worse in this regard. (Why is that?)


    I've tried feeding the pll_locked signal from the respective PLL into the OPL3's reset signal, I've tried anding pll_locked from all three PLLs (Yes, three PLLs - this project contains *loads* of different clocks!) into the gen_reset module, and clocked that from clk8 rather than a generated clock, synchronised the reset signal into the target clock domain too, and even tried bypassing the reset module entirely since the V2 port doesn't even use one - none of it makes any difference!


    I think there's a bug in the OPL3 module somewhere, because while pressing the freeze button brings it into life, pressing it repeatedly will switch it randomly between working and non-working states. I've just tried giving the V2 version a similar OPL3-specific reset on the freeze button, and I can get it into a non-working state even on V2 - the difference is on V2 it always powers up into a working state, and on V1 it always powers up into a non-working state. On another Cyclone III board I have here it always powers up working, so it's not a C3 vs C10 thing. So I'm out of ideas for now!


    I'll come back to it after teaching the Minimig core how to talk MIDI.

  • though I didn't know the Cyclone 10 was worse in this regard. (Why is that?)

    I can only speculate about that, but with Cyclone 10 having about the same technical data as the Cyclone 3, it's probably just a re-make using a different fab.


    Before Altera was bought by Intel, they used to produce their chips at TSMC. I suspect that Intel has enough idle capacity for a 65nm process, and they have enough knowledge to run a 65nm fab for a 60nm chip. Given that their own support staff has no idea about PLL (re-)configuration and the behaviour of the two chip families is substantially different, although the technical data is exactly the same, they probably just went with "we have a product at a very competitive price point, let's ship!".


    Haven't downloaded more recent Cyclone 10 documentation, but I'd expect a few erratas to be available now :-)


    I think there's a bug in the OPL3 module somewhere, because while pressing the freeze button brings it into life, pressing it repeatedly will switch it randomly between working and non-working states.

    Quick'n dirty hack: Make the OLP3 reset signal software-controllable and find a way to detect if that part is working properly. Then you can press/release that signal a few times until it starts properly. I'd put that Kickstart-routine into the same software block that also loads the BIOS. Surely not a "clean" solution, but one that will get your head off the problem. If you mark that workaround with a red flag, maybe hand it back over to the original author, he may find the cause rather quickly.

  • i copied the two files on a random SD card with tons of other stuff on it, started the core - and it worked fine. that was a LOT easier than preparing the card for the original core :) thumbs up!

  • C128? Hmm.. never thought about it, probably because there is no notable software for the C128 that isn't available for the C64 as well.

    Well there is some truth to that.
    However the C128 user-base is really forgotten, seen as a 'failure' selling ~5 million units.

    Without using a monitor like 1084S or some convoluted RGBI to CGA/VGA box there is no 80 columns.


    Sure it will be odd using a 64 keyboard for 128 but I do miss using the far more useful BASIC 7.

    I guess the main reason that many bork at this idea is the implementation of the VDC 8563/68.

    A reason for doing a C128 I've also thought is that it is clearly stated don't use chameleon with the C128s

  • I tried it and works flawless...

    Looks like space for optimization: That circuit generates 2.5V from the 5V pin of the A/V output. If the load is los anyway, you can generate that voltage with a few diodes from H/V-sync, which are mostly at high-level anyway. Charge a cap through diodes, and you can save one connector.

  • Thanks - we're deviating from the original topic, so let's keep it at that for now.


    If Basic 7.0 is really such a big point, it shouldn't be too hard to port that to the C64. We have lots of memory on the C64 core after all, and if someone knows his way around the C128 and the MMU of the Chameleon, it should be possible to use Basic 7.0 by using additional RAM for the required 28k ROM. The "BANK" command would probably have to be re-written to make use of the Chameleon MMU, but then it should be possible to have a few hundred k Basic Bytes free and Basic 7.0 on a C64. Anything using the 40-column screen sould work, as even POKEs would go to the same addresses.


    Question is: What programs really make use of Basic 7.0? Is all that effort really worth it?



  • Gave the next186 core a try on my old v1 chameleon and decided to give a few things a go. Unfortunatly my results were somewhat mixed.


    A pity it dosen't emulate a 386 if it had that'd brought in some of the older dos based emulators.


    Some things worked better than others and some things didn't seem to work at all -- there seems to be lots of issues with graphics at the moment. For example locoscript (more famous on the old amstrad pcw machines although there is a PC version too) started ok but the cursor used to select files just seems to "draw all over the screen".


    Turbo pascal 4 also runs and compiles ok - but seems to suffer from corrupted text in graphics mode. Qbasic will run as well but the graphics aren't quite 100%; for example try this:


    Code
    1. screen 9
    2. circle (100,100),50
    3. for t=1 to 15
    4. print t
    5. next


    The circle will show OK but the numbers from 1 to 15 appear as corrupted blocks of colour.


    BTW is this what the chameleon version is based apon btw? If it is then (just purely for curiositys' sake) that website mentions the next186 core being able to run windows 3.0 . I did try this but I'm not sure how they got it to work; the installer crashed with a "divide by zero" error while installing on another machine ended up with video corruption and an error "cannot find network.drv" x.x



    ljones

  • Quote

    Gave the next186 core a try on my old v1 chameleon and decided to give a few things a go. Unfortunatly my results were somewhat mixed.


    A pity it dosen't emulate a 386 if it had that'd brought in some of the older dos based emulators.

    Yes indeed - though a 386 is a *much* more complicated beast - not just the 32-bit registers but the MMU. The core is capable of running EMU386 though. I don't know enough about DOS to know whether or not that's useful.


    Quote

    BTW is this what the chameleon version is based apon btw? If it is then (just purely for curiositys' sake) that website mentions the next186 core being able to run windows 3.0 . I did try this but I'm not sure how they got it to work; the installer crashed with a "divide by zero" error while installing on another machine ended up with video corruption and an error "cannot find network.drv" x.x

    Yes, that's the original core. I haven't attempted running Windows yet, but I have tried running Breadbox Ensemble (with no luck as yet) and OpenGEM - which does work.


    As I say, I don't really know much about DOS in general, so I've no idea whether my inability to run Breadbox Ensemble was due to me using FreeDOS rather than MSDOS or whether something else is preventing it from running.

  • I would absolutely love to see a 128 core, but I know I am in rare company. I'm one of the few people who appreciate the VDC.

    What I would think should be more realistic? A SuperCPU core maybe?