Minimig on v2

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.
  • Amiga firmware stopped working for me. Rather, it does not work with the monitor (connected different). He writes this:


    No Signal
    entrance HD15

    On any version of Chameleon firmware and with any version of Amiga firmware


    Commodore works


    Chameleon v2 does not work with the monitor in Amiga mode

    https://www.youtube.com/watch?v=5I6CVyYpmNM


    Monitors I change does not help

    Wire changer does not help

    Maybe I clicked some kind of wrong bunch of buttons?

    I repeated Chameleon again several times. I upgraded different firmware both old and new - nothing helps.

  • I have ran the Amiga core for many months, but there are two things I would like to have added for me to use it for anything other then gaming:


    Networking through the connected rr-net

    Graphics enhanced through for example P96 for higher resolutions that the TC64 supports.


    A humble request perhaps for robinsonb5 ... ... please!!!

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

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

    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.


    Tremendous amount of work would not be good though, perhaps a joint effort would do the trick. I understand the limited time one has to make a family work smoothly. However I would be really happy for it.

    Yours sincerely,

    Jan Blomqvist

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

  • Well, it was just a thought because it works in the 64 core, perhaps it completely different, was just hoping for a working solution.

    /Jan

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

    Yes, the clock port shares address and data lines with the C64. However, the core can find out if it's running in cartridge mode or standalone mode by looking at the Phi2 clock: if it's toggling, it's in C64-cartridge mode. If it's at a fixed level, it's in stand-alone mode. The level then says if a Docking Station is connected or not (see core developer's manual for the actual polarity), so it's vertainly possible to make a core that is not dangerous to a connected C64.


    Trouble is that there are no Amiga drivers for the RR-Net networking chip. Since it's not capable of doing IRQs in 8-bit mode, it would require a timer-IRQ for checking regularly if the chip wants "something" to be served network-wise. That would be darn slow, and still require the same amount of development work that the X-Surf drivers took.


    So from my side, I can only point to the A1200 Reloaded that we're planing: It'll have 100MBit network as standard.

  • Yes, the clock port shares address and data lines with the C64. However, the core can find out if it's running in cartridge mode or standalone mode by looking at the Phi2 clock: if it's toggling, it's in C64-cartridge mode. If it's at a fixed level, it's in stand-alone mode. The level then says if a Docking Station is connected or not (see core developer's manual for the actual polarity), so it's vertainly possible to make a core that is not dangerous to a connected C64.


    Trouble is that there are no Amiga drivers for the RR-Net networking chip. Since it's not capable of doing IRQs in 8-bit mode, it would require a timer-IRQ for checking regularly if the chip wants "something" to be served network-wise. That would be darn slow, and still require the same amount of development work that the X-Surf drivers took.


    So from my side, I can only point to the A1200 Reloaded that we're planing: It'll have 100MBit network as standard.

    I think it's really cool to sit on my c64 and run Amiga OS. Just that I would like to be able to do more then just gaming.


    A1200 reloaded will be an interesting project do you have any specs on what it will hold?

  • Very cool, just a couple of questions... ...DVI, really? No digital sound. And now about PPC?

    THis is going off-topic - I have just updated that page with the HDMI+RGB specs that the new flicker fixer Indivision AGA MK3 will have.


    PPC is not a part of the spec, as the CPU is located on the accelerator. You can of course attach a PPC card if you have one, but since software is so scarce and even we don't own a PPC card (not even a single unit in private posession of our employees), it's just not a part of the Amiga history that we want to (or even "can") address.

    BTT :-)

  • 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

    I really appreciate your ports to v2 and recent bug fixes. Any chance updating the core to a later Minimig build? It seems you are the only one that understands the Minimig core. I'd chip into a bounty if that helped.

    Otherwise, one major request would be to map the C64 keyboard to the Minimig core. I'd absolutely love to be able to use the 64 keyboard and not a ps/2 one on the breakout cable.