Posts by robinsonb5

Quote from Jens

How would the auto-switch logic know when not to do automatic switching? Most hardware-based auto switchers use the fire button as their switch signal. This would work nicely if you're just swapping ports 1 and 3. However, if you're playing a 4-player game, this automatic switching should be disabled, as you'd swap around players all the time. Might be a nice extra difficulty playing Dynablaster, but probably annoying in the long run

The logic I'm using at the moment is to look for "impossible" joystick readings - left and right simultaneously or up and down simultaneously, and to mark port 3 as containing a mouse when such a combination is detected. I clear that flag any time the fire button in port 1 is pressed.

Then the core switches to port 1 any time port 1's fire button is pressed, and only switches to port 3 when port 3's fire button is pressed while the port_3_mouse flag is set.

That way it should avoid phantom swapping during 4-player games.

The problem is that the TC64 goes into what I presume is a debugging screen if the joystick in port 1 is held left or down at powerup. There's a pretty good chance that a randomly parked mouse will be pulling down on one of those two lines.

(A bit of experimentation suggests that pressing the leftmost button on the Chameleon will exit the debug screen - the mouse will then interfere with the menus of course, so as you say, using port 3 for the mouse is a smart workaround, and with some auto-switch logic also means you can play two-player joystick games without having to unplug the mouse.)

I've played a bit with this today, and it looks like making ports 1 and 3 act as an automatic joystick / mouse switcher will be fairly easy (while still allowing four joysticks.)

Quote from MethanoidPete

Is the OSD_CA01.sys file mentioned in some other posts still required? it doesnt seem to be included in the newer Minimig TC64-V2 archive.

The OSD_CA01.sys file is the firmware for the ECS Minimig core (it's a chunk of 68k code which runs on a second TG68 CPU, handling disk emulation, menus, etc.) - the AGA core uses different firmware running on the much smaller 832 CPU (written specifically for the AGA core, and subsequently used when porting other cores.)

Your HD problems sound very odd - I just created a very small HDF with two partitions, formatted them both as FFS and zipped the resulting file - does this mount correctly on your setup?

Which OS / Kickstart version are you using?

Quote from -trb-

As this core is in an early stage, porting it to TC64 probably does not make sense now. But what are the odds that this core is portable to TC64 at all?

That core's sudden appearance came as a real surprise! I immediately downloaded it and did a dummy build against an FPGA in the same class as the Chameleon64's Cyclone III, to get an idea of the space required:

Total Logic Elements: 42,312 (The TC64 has a little under 25,000)

M9Ks (internal memory blocks): 441. (The TC64 has 66, and my SD Card / Menu framework needs 12 of those)

Admittedly that includes emulation of both 1541 and 1581 drives, and also some video stuff which isn't applicable to TC64 - and it might be possible to move some of what's currently in internal memory into SDRAM, but realistically I don't think there's much hope of this core fitting the TC64.

Quote from Tobias

If that is the case - there must be some resource that tells use what polarity a monitor is supposed to see for a specific mode? Where is it?

The best source of information I've found so far is https://glenwing.github.io/docs/VESA-DMT-1.13.pdf

Quote from Tobias

sync polarity - which shouldnt even matter much with modern TFT displays.

Sync polarity can matter with modern TFT displays, because it's one of the cues the screen uses to guess what the incoming screenmode is, and thus how many pixels it should sample. For example, if I feed a DblNTSC screen to my Dell U2311, it will guess that it's looking at either 640x480 or 720x400 depending on sync polarity (which can be adjusted with a BEAMCON0 tooltype in the monitor driver's icon). It's smart enough to adapt the vertical resolution to the number of actual active scanlines, but when it only samples 640 pixels and the Amiga's outputting 720 the result is a fuzzy mess.

This one's mostly for V2 users, since there's already a Speccy core for V1 hardware - but I've ported the MiST ZX Spectrum core to TC64 - see http://retroramblings.net/?page_id=1880

There's no direct SD card or HDF access as yet, but floppy images, tape images and snapshots should work.

As usual the C64 keyboard and joystick is supported.

(I also noticed that the Speccy core for V1 on the Wiki seems to a dead link - though it can still be accessed using archive.org's Wayback machine - so maybe this core will be useful for V1 users after all...)

Quote from Forrest-J

Why can't I even get into the menu for the Gameboy core? Whether PS/2 keyboard, original C64... Nothing works:-(((((

Do you see anything on screen at all? Do you have the GBC_BIOS.BIN file on your SD card?

Quote from el_pasi

Yes, Amstrad-core works fine. And just checked, newest Mistery works if I load Rom manually from menu.

Thank you - so it looks like the problem is related to configuration files. I will investigate...

(Are your ROM files in the root of the SD card or a subdirectory?)

Quote from turrican9

It seems I can change and save settings if I save to the default config file on both my Sandisk cards. So I must be remembering wrong then. I was sure I had problems even saving to the default config on one of my Sandisk cards. If I try to save to any of the numbered slots I just get an error saying it cannot create the config file.

OK great - I will attempt to get file creation working one of these days, but as a workaround you can copy the MINMGAA.CFG file to MINMGAA1.CFG (where the "1" can be any number up to 4) - then you should be able to save to the other slots.

Quote from turrican9

A 16GB Sandisk Ultra SD card I have still cannot create a config file using the latest AGA core. I have to copy the config file manually from PC. That also means if I change settings from the minimig menu I cannot save to that config file either.

Creating configuration files is known to be buggy - but saving over the top of an existing file should be working. Can you describe what happens when you try, please?

Quote from el_pasi

I tried this newest Atari ST core (20220325) with standalone TC64v1 and it didn't boot. There's no Atari-logo, just only graphic garbage. OSD works, so probably has something to do with SD-card initialization? Had same kind of problem with newest Turbografx-core (20220225), whose OSD just reports "SD FAILED". I reverted back to earlier cores (Mistery 20211010 and turbografx 20210627) and those work fine. Newest Minimig-core (20220225) works, didn't see SD or other problems there.

Interesting - there have been some changes to SD card handling in the latest framework, but the Amstrad core has them too, that that one works for you?

Since the OSD works in MiSTery, could you try loading a ROM manually from the menu?

For the Turbografx core I did move the controller to a faster clock on TC64v1 because it was having trouble keeping up with CD audio (direct SD card access is a pain on TC64V1, since it has to go through the CPLD Multiplexer.) - I'll see if I can figure out what could be causing it to fail.

I've just made a first release of the Amstrad 464 / 6128 core, ported from MiST to Turbo Chameleon 64. It can be found here: http://retroramblings.net/?page_id=1859

Have fun!

Here's a test version which should solve the menu-with-C64-keyboard problems - could you let me know if this works for you, please?

(Make sure you download the correct version for your Chameleon - use the V1 version if your Chameleon has a breakout cable for PS/2 keyboard/mouse and power and three blue buttons. Use the V2 version if your Chameleon has three mini-DIN sockets in a row, for IEC, Mouse and Keyboard, and the buttons are black, white and red.)

Quote from root

Hello,

The C64 keyboard is very buggy in the OSD. It's impossible to use it.

Thanks, I'll take a look. (I suspect my framework's generating a joystick button press from the Enter keypress, as well as a key event, and the menu's responding to both of them.)

Thanks for the bug report. Does it also happen with the previous release (of both the core and firmware), or is it a new problem?

Quote from SID-6581

For my understanding, I ask whether you have implemented the scandoubler function that we talked about earlier in this article?

Sorry, no, not yet. The sync inversion mentioned in the release notes is purely to address the problem grianiag mentioned in the "minimig problems" thread. It's just a possible way of getting better results on picky monitors.

Quote from turrican9

i have the same problem on my lcd tv. Would be nice to get this core with the inverted setting as a download on the retro ramblings webpage. Together with the info

Yes indeed, now I know it helps and doesn indeed solve the problem I'll make it "official". It would be helpful to know whether it messes up 31KHz AGA screenmodes, though - i.e. DblPAL, DblNTSC and Multiscan: Productivity. It might be necessary to restrict the sync inversion to scandoubled PAL/NTSC. (It's already bypassed in RTG mode, since the sync polarity can be set, if necessary, in P96Mode.)

Quote from grianaig

Is it that I need an 800x600 resolution to fit all the game in on the MinimigAGA TC64V2 core?

Your advice is appreciated.

Could you try the attached version, please? I think what's happening is that the ECS version of the core is inverting the H and V sync signals on V2 hardware. It shouldn't be, and that was corrected for the AGA core - however I suspect your monitor actually likes the inverted signals better.

This test version of the core - and associated firmware, which you will need to put on the SD card - will invert the sync signals if you hold down F5 or F6 during boot. (F5 forces NTSC with inverted sync, F6 forces PAL with inverted sync.)

If it works, you can make the setting persistent by saving the default config file.