Posts by redrumloa

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.

    You'll have to go to the menu first, images will only be updated when you enter the menu.

    That's odd. I did that last night and it didn't update. I just went to record myself doing it and it actually updated. I suppose I have to chalk it up to user error, despite what I remember. Oh well, issue closed.

    I mounted Geos.D64 as device 8. I mount GeoCham64RTC.D64 as device 9. I set to ALWAYS update mounted images. I go in Geos and drag the GeoCham64RTC file to Drive A. The LEDs flash as if it is updating the image. However, when I reboot the system and go back into Geos, nothing has changed. I tried without Turbo on, no change.


    Any ideas? I have Beta 9q.

    Clearly, looking at the pictures from the facebook group, TC64 V1 shows the exact same ghosting as the TC64 V2 does.

    I have a v1 and have never seen any ghosting. I've used at least 4 different LCD monitors during this time and not seen ghosting on any of them. That's using both PAL and NTSC 64s. IIRC I've only used as standalone with 1 LCD, but no ghosting seen there either.

    Transcend is usually OK, so my first question would be: Does it work in an SD-card reader on a PC, and does that have to be SDHC-rated?


    Yes it works fine in my PC with SD card reader. I've had this SD card for some years and have used it in a number of devices, including Windows based PC. I even used Diskpart to 'Clean' and start from scratch, no change.

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

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

    Got around to trying this out. Very promising. A few games I just tried worked, including Duke Nukem 1. This could make a good core for the TC.


    Did you happen to see the posts from the guy porting it to ZXUno? He seems to be squashing some bugs on his branch. Not sure how that could translate back for MISTer or TC.

    I use my Turbo Chameleon a lot. I use additional cores a lot also, so much so that I have different SD cards for each major core. With the SD2IEC you can create a swaplist to switch between D64s. Could something like that be implemented? Put a text file in the root folder with a simple instruction to auto launch a specific core? If that text file is not found, it would load normally. The SD card with MimigAGA install could auto launch the MinimigAGA core. The SD card with Atari ST install could auto launch the Atari ST core.


    Not sure how easy this would be to implement, so kindly asking here to see if it is.


    Thanks again for such wonderful hardware.

    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.

    What I would die on the hill for is an updated Minimig core! Is there any chance of this? I'd love to see a core coming closer to where MISTer is these days. I'd also die for the Minimig core to be mapped to the 64 keyboard!

    -Edit-

    I'll ask robinsonb5 over in the Minimig v2 thread, but last time I asked him he didn't seem too interested in pushing it any further beyond bug fixes.

    A SuperCPU comes up quite often in discussions. However if you look realistically there are only a handful of programs that really use the 16 bit instruction set of the 65816 processor. Most of the SuperCPU titles just want the faster speed that is already covered with the existing turbo functionality. Designing a new core for running just two extra programs is a bit meh.

    It depends how you look at it. I get a good bit of use out of my SuperCPU 128, more than 2 programs for sure :-p.

    A SuperCPU core is not something I'd die on the hill for, but i just see it as long hanging fruit. The hardware is already there. The buttons are already there. SuperCPU are going for cRaZy amounts on eBay, I mean as in $2,500+ for a 64 version to $5,000 for a 128 version on eBay. There are at least 2 different attempts ongoing to clone it, that may never pan out. There's got to be some sort of demand for a clone? Also most other cores are entire other platforms, this is for a 64 expansion.

    Compared to other cores, wouldn't this be much easier? Aren't there open source 65816 cores out there? The SuperCPU core could ignore other 64 core features. Wouldn't it be a long night or 2? ;-)

    I'm not an FPGA developer and just thinking out loud here. How hard would it really be to implement a basic SuperCPU core with no bells and whistles?