Posts by robinsonb5

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.


Also users that are not logged in can not create new threads. This is a, unfortunately needed, counter measure against spam. Please create an account and log in to start new threads.

Don't Panic. Please wash hands.

  • List of FPGA cores that could be ported to Chameleon hardware

    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.

  • Minimig on v2

    I've just released updated Minimig cores for both V1 and V2 hardware which should solve both the boot problem discussed earlier in this thread and the configuration file problem mentioned elsewhere in the forum - a really stupid masking bug, a "0xff00000" which should have been "0xff000000"!


    Updated cores can be found here: http://retroramblings.net/?page_id=276

  • Latest MiniMig core on V1

    Quote from dbugster

    By firmware do you mean the OSD.sys file ? By doing that I just got a "initializing sd card loop" on the first blue screen when I reset the MiniMig core :-( Im reverting to the old MiniMig core for now .. Btw this is with dockingstation v1.

    I found a really stupid masking bug in the firmware which I think was causing both this problem and the boot problem other people had experienced with the V2 core - namely a "0xff00000" which should have been "0xff000000"! Updated cores can be found here: http://retroramblings.net/?page_id=276

  • Minimig on v2

    Quote from JanBlomqvist

    When it comes to the address and datalines are shared, wouldn't it be equally difficult to do it on the c64 core too then? I'm running networking with my c64 core all the time, so perhaps there are solutions to that problem or it only applies to the minimig core.


    When it comes to slow sdram, I can't say very much other then if I had high resolution I could wait a little longer for the otherwise fast screen updates.

    While it's arguably equally difficult for the C64 core, it's also an already solved problem, because in cartridge mode coordinating between the FPGA and associated hardware and the real C64 is the whole point of the core!

    I don't know (yet) how difficult it is to access the clockport without treading on the C64's toes -it might not be any more difficult than the current Chameleon IO module. I don't know whether the reason Christian didn't do was that he doesn't have the right hardware, wasn't interested in it, or whether it's just really difficult!

  • Minimig on v2

    Christian Vogelgsang did create a fork of the core (for V1 hardware) some time ago which makes the clock port visible to the Minimig, so it's definitely possible - however it can't work while the TC64's connected to a real C64 - and might even be hazardous to a C64, since (if I understand his blog post correctly) the address and data lines are shared between the cartridge connector and the clockport. http://lallafa.de/blog/2013/09…for-chameleon64s-minimig/


    I don't know how difficult it would be to solve that issue - or if it's even possible, but I don't currently have any clockport peripherals for testing, so I'll add that one to the "Maybe one day" list.


    As for P96/RTG support - it would be great to have this, but it's a tremendous amount of work and the result is likely to be pretty slow since we have just a single 16-bit-wide SDRAM chip to work with.

  • Latest MiniMig core on V1

    Thanks for the report - I'll take a look. Does it work if you use the firmware from the previous release? (There are no new features in the firmware, it's just been built differently to work better with the new bootloader. There was a problem where the firmware would fail to reload if you hit the reset button.)

  • Minimig on v2

    The Minimig core now has MIDI support using the second-generation docking station.

    Snapshots for both V1 and V2 hardware can be found here: http://retroramblings.net/?page_id=276


    As a bonus, this version adds a "Button B -> Joystick Up" mapping when using a CDTV pad - to toggle between this and normal operation, hold down button B while sliding the "mouse/joy" switch.

  • List of FPGA cores that could be ported to Chameleon hardware

    Quote from Jens

    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.

  • List of FPGA cores that could be ported to Chameleon hardware

    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

  • List of FPGA cores that could be ported to Chameleon hardware

    Quote from Tobias

    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.

  • General question anout the Chameleon setup

    For what it's worth, the Chameleon V1 hardware was my first introduction to FPGAs, and it actually serves quite well as a dev board as long as you don't mind soldering on a JTAG header, and not having very many GPIOs. The V2 hardware is better since you don't have to worry about multiplexing when reading the SD card.


    Since then I've acquired a DE1 (original model) with Cyclone II, DE2 (also original model with 35 thousand logic elements) with Cylone II, a MIST with Cyclone III, a couple of cheap Chinese import boards with Cyclone III, a couple of cheap import boards with Cyclone IV, a couple of BeMIcro Cv boards with Cyclone V (are you spotting a pattern here?), and now a Chameleon V2 with Cyclone 10. The DE2 is currently my go-to board for new projects - even though it's now totally outdated - because it has a nice lot of switches, buttons and GPIOs, plus an RS232 port, which helps a lot with debugging. Some of the newer boards have a hybrid FPGA containing an ARM CPU as well as the programmable logic, which adds greatly to the capabilities, but also adds an extra layer of complexity.


    The insights I've gained from tinkering with these have been as follows:

    • Pay attention not just to the number of logic elements but also the amount of block RAM offered by FPGAs. The logic of the Next186 core would comfortably fit twice in the DE2, but there's not enough block RAM for even a single instance!
    • Pay attention to SDRAM options. As a beginner you probably want 16-bit wide single-data-rate SDRAM because that's what the most accessible and easy-to-understand projects use. (There are also plenty of smaller projects that don't need external RAM at all - such as the Chameleon arcade cores.) 32 megabytes seems to be the most common amount, though the original DE1 and DE2 have only 8 megabytes on board.
    • Pay attention to GPIOs and whether they're directly accessible via hobbyist friendly means. Attempting to interface a home-made PCB or stripboard project to an HSMC socket is going to be frustrating!
    • Pay attention to which series FPGA you choose, and which version of the software you'll need for it. For Altera (now Intel) FPGAs the free version of Quartus only supports a few types, and which ones changes from version to version - I think 13.0.1 was the last version to support Cyclone II FPGAs, while 14.0 dropped support for Cyclone III. I currently have 13.0.1sp1 and 18.1 installed so I can build for DE1/2, Chameleon V1, MIST and also Chameleon V2.
    • Again Altera / Intel specific, but make learning how to use SignalTap an early priority - it's unbelievably useful.


    You might find my blog helpful - I documented some of my tinkerings here: http://retroramblings.net

  • List of FPGA cores that could be ported to Chameleon hardware

    Quote from Tobias

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


    Quote from Tobias

    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.

  • List of FPGA cores that could be ported to Chameleon hardware

    Quote from Tobias

    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.