Posts by robinsonb5

Quote from Tobias

runs for me, i can load and execute .pce file, sound works, display works. F12 menu works. actual console controls (via joystick or keyboard) do not work

OK that's strange - C64 joystick, PS/2 keyboard and CDTV remote all work here. The only thing I'd overlooked is that I'd forgotten that joystick port 1 interferes with keyboard scanning, and because the V2 io module merges CDTV remote buttons into the C64 keyboard matrix, that was causing some interference. See if you have more luck with this one?

(The io module still isn't working 100% by the way - I ran the HWTest a few minutes ago (via JTAG), and neither keyboard nor joystick worked at all. I then re-ran it via JTAG half a dozen times and it was fine every time.)

And on another note, I've just uploaded an initial port of the PC Engine core: http://retroramblings.net/?page_id=969

Quote from Tobias

I moved the posts related to troubleshooting minimig here: Minimig on v2

Good idea!

And on another note, I've just uploaded an initial port of the PC Engine core: http://retroramblings.net/?page_id=969

Quote from jab76

Weird that I get a red screen with the non-working OSD_CA01.sys file and others don't seem to.

I think because the non-working OSD_CA01.sys is larger, it's placing a different part of the code in the portion of SDRAM that's causing trouble, so changing the symptom to a boot failure rather than a corrupted menu. Same cause - SDRAM problem - but a different symptom because the code layout is different.

Could you try with the attached OSD_CA01.sys file, please? It won't boot the Minimig, but instead it will conduct a memory test (of just the portion of memory visible to the OSD module) - could you let me know whether you get loads of bad addresses scrolling by, or just a few, and maybe post a screenshot of the output?

Also, could you try this core - http://wiki.icomp.de/w/images/d/df/Chameleon_hwtest.zip (make sure you use the V2 version of the core) - and let me know whether the middle animated stripe remains green at all times or goes red at all?

Quote from jab76

You're right, it didn't run as smooth as in the video. I'm not familiar with the game, so I didn't know how smooth it runs with more ram.

OK, thanks - it's all useful data.

I've updated my post above with a couple more cores to try - when you get a chance please let me know if either of them performs better.

Also, just out of interest, how are you powering your Chameleon?

Quote from jab76

I've enabled fast RAM and booted into Workbench. Both 1.3 and 3.1 and with kick 1.3 and 3.1. I didn't notice anything not working. I did think that the memory was displayed weird though as I'd enabled fast RAM, but avail didn't show any (not even after a reset).

OK, well if the Fast RAM's not being reported in workbench after a reset then the Amiga's detecting that the RAM's not working properly and thus not adding it to the pool. So that's more evidence for an SDRAM problem.

I'm guessing Zeewolf 2 doesn't run as smoothly/quickly as this? https://youtu.be/twFhmBbL2vc?t=156

That's how it should run with Fast RAM and Turbo Chip RAM enabled.

I'll do a couple of builds with the SDRAM clock shifted each way by half a nanosecond and see if it makes any difference.

EDIT: Attached - two .rbf files. Both work fine on my TC64v2. Please test them both with the non-working OSD_CA01.sys file, and repeat the workbench / Zeewolf 2 tests.

Quote from Jens

Mem corruption? Wrong phase relation between SD-Ram clock and SD-Ram address/commands and/or SD-Ram data? The Winbond RAMs are very forgiving if it comes to overclocking and setup/hold times, so they may "appear to work" even if the clock phase is off by 150 degrees.

It certainly looks like an SDRAM issue since the scrambled data isn't deterministic. The clock / phase relationship should be OK, though, since it hasn't changed since the V1 core, and the SDRAM signals meet IO timing in TimeQuest (they're about the only part of the core that does meet timing!).

jab76, could you do a couple of tests for me, please? Could you enable fast RAM in the OSD, then boot a workbench / system friendly disk of some kind, and let me know if it's stable? (When SDRAM timing's off, it's possible for single reads to work fine, but burst reads to fail - and Fast RAM uses burst reads.)

Also could you see if Zeewolf 2 works, please? (That's a game I use as a smoketest, since it takes advantage of Fast RAM, and is also made more playable by the Turbo ChipRAM option.)

Quote from jab76

However the VIDEO settings in the OSD all looks garbled. Is that a known issue? Does anyone else have this?

btw, I'm using the OSD file that Tobias posted earlier (Cores ported to Chameleon V2), as I get a red screen when using the one from Retro Ramblings (Cores ported to Chameleon V2).

Any chance you could post a photo of the corruption?

Quote from celco001

Just 2 questions if I may:

- Is it possible to get the Amiga OS on full screen? At the startup from the minimig core and the Amiga OS there are black borders on the screen.

It's not possible to adjust this from within the core - but does your monitor not have sizing options on its control panel? If there's no horizontal size look for a pixel clock option - this sometimes adjusts the horizontal size as a side-effect.

On workbench you can always use the overscan prefs to use more of the screen.

Quote from jab76

I did just that of course, but forgot to mention it. Sorry. The one from retro ramblings is 68.91 kb and the other one is 57.36 kb. Hope that helps. Thanks!

Hmmm, very strange - that version definitely works here. What platform are you using to extract the zipfile?

Quote from jab76

sing the sys file that Tobias posted did the trick. It also is different in size from the one from the zip file from retroramblings. Now to find a proper keyboard that works

That's great news! Could you do me a favour, though - could you try re-downloading from retroramblings, and testing again with a fresh copy of the firmware from the zip file? It should work, so I suspect either the download got corrupted or truncated, or the file got corrupted when written to SD card.

Quote from Tobias

yep. of course if thats what you want to do - you can still do it. but you cant start other cores (except with chaco) then

RIght, that's what I thought. I was confused because out-of-the-box the "Launch core" menu (and chacocmd --info) shows slot zero as "empty" rather than occupied by the C64 core. I suspect that might result in people replacing the C64 core without meaning to.

Quote from celco001

@robinsonb5. Many thanks for all the work. Is there something a site or pdf from a how to install... and requirements for the minimig core? As far as I can understand I followed the known instructions but nothing happens when I turn on the TC V2.

Many thanks.

The Chameleon's user manual is here: http://wiki.icomp.de/wiki/Chameleon#User_Information

You should flash the .rbf file to a core slot - ideally slot 1 or higher. (Correct me if I'm wrong, Jens / Tobias - flashing a core to slot 0 will replace the default C64 core?)

The OSD_CA01.sys file needs to go on the SD card along with a kickstart ROM file, called kick.rom

By default the Minimig core puts out a scandoubled PAL video signal, 31Khz horizontal, 50Hz vertical scanrates, and not all monitors can cope with that. Try holding down F1 on the PS/2 keyboard while pressing the reset button to force scandoubled NTSC mode (60Hz) which more monitors can cope with, F3 for 480i NTSC video, or F4 for 576i PAL video.

Quote from Tobias

you also need the OSD_CA01.sys in the root of the SD card, perhaps it should go into the distributed zip

Yes, indeed - a corrupted OSD_CA01.sys file could cause this, so definitely worth trying the attachment here. But I suspect it's not that - I'll do a build with the Action Replay disabled, since I remember that module causing me grief a few years back.

Thanks for testing.

Quote from jab76

I get an error whilst trying to run the Minimig core.

I get a red screen after loading the kick.rom file and an error message saying "Exiting bootloader..." --> "Incompatible Menue firmware!".

I've used the mot recent 2019-03-21 files. And a 1.3 kick rom image from Amiga Forever.

OK that's strange - after the "Exiting bootloader..." line appears it shouldn't be possible for the incompatible firmware message to appear, because at that point the boot code should vanish from the Amiga's memory map, and hand over to the newly-uploaded Kickstart.

Standard advice when hitting problems with an FPGA core is to try a different SD card. I don't think it will help in this case, but just to be sure, could you try it?

Also, could you try this .rbf file instead? It's exactly the same thing but compiled with different optimisation settings, which re-rolls the dice regarding the minimig core's build-to-build stability issues. If this behaves in exactly the same way, then report back and I'll see what else we can try.

Is anyone else having problems?

Quote from mpryon

What level of CPU is a realistic goal for this? Could it do a 68020 or 030

The Minimig core already has a 68020-level CPU (though not perfectly compatible) which runs at roughly 40MHz '030 speeds.

The fastest CPU I've seen running this kind of FPGA so far is a pipelined MIPS core complete with branch prediction, roughly comparable speed-wise to a first generation Pentium. The Vampire's CPU core runs on a comparable (though larger) FPGA, and is, I believe, faster still.

Quote from Jens

The Spectrum core for the V1 hardware is kinda difficult to port to V2, as it does not use our Chameleon IO instance, but "something self-made", which would have to be ported to the new hardware. I have my doubts that anyone else than the original author can do that in acceptable time, but the original author has no interest in that core any more

Is the source for that core publicly available? In a moment of curiosity I could only find binaries.

Since there are now many, many FPGA cores out there, it might be a good idea to maintain a list of known cores and their current status, so anyone interested in tackling a core can see which ones are in progress and which ones need a port?

Initial port of the Minimig Core - enjoy!: http://retroramblings.net/?page_id=276

Quote from mbruines197703

AGA has more bandwith, so it can acces memory faster. This can be a good benefit for games and on WorkBench applications.

The ECS Minimig core already has Turbo ChipRAM so you get some of those benefits already. (Zeewolf 2 runs really nicely, for example.)

I'm not making any promises regarding the AGA core because it involves porting not just the chipset design, but also the firmware in the MIST's onboard microcontroller - which the Chameleon has to replicate within the FPGA as a second CPU (which is why it might not fit). For the forseeable future I'll only be tackling the low-hanging fruit - porting the existing ChameleonV1 cores.

Quote from espskog

Tobias: Alastair Robinson who ported the MiniMig core to the V1 is on our Fb group and he says he has downloaded Quartus and the example V2 code and I am sure he is willing to give it a try, but it would be great if you got in touch with him.

Yup, that's me!