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.
-
The PCXT core should give some video output even if ROM loading fails - it has a text-mode splash screen.
I just flashed the version linked above to my TC64V1 to test it, and started the core with no SD card inserted. I see the splash screen appear, then a few seconds later the OSD pops up to tell me that SD reading failed.
I'm wondering if maybe your monitor doesn't like the core's video output? Is the monitor going into power-save mode? If you press the leftmost button on the TC64 does the menu appear?
-
Can the forced reset be disabled when a disk access beyond track 79 happens?
This is an issue with Rock'n'Roll. This game has no copy protection, but it writes the high scores to track 80 in its own format.
Good point. I do want to try and add support for extended ADFs at some point, but in the meantime I could certainly make the error non-fatal.
-
robinsonb5 Hey, just pinging you to see if you could provide any insight about the NTSC clock frequency question above.
I'll be honest, I don't know enough about the Atari ST to comment on whether the clock speeds could cause the issue you're talking about. But I can confirm that the core runs on a fixed 32.084 base clock.
The frequency being slightly off shouldn't cause anything to fail, because everything else is derived from that clock - so the entire machine will just run slightly faster or slower than intended. If there's a difference between PAL and NTSC machines in how the clock's subdivided to make slower clocks then that could account for a difference, but I don't know enough about the ST to know whether that's the case.
-
I now tried another SD card from Transcend with a cluster size of 32k which seems to work fine!
Really cool to see Cubase running!!!!
Thanks for the update. I'm pretty sure the problem is something timing out because seeks are taking too long - so I'll still revisit this at some point and see if I can improve things.
-
Thanks, I'll take a look in the near future.
-
I downloaded this core for my TC64V2. And now I can write to images without them going corrupt. However, I no longer see an option to save the profile to the config file? I think I had this option on the older cores from the retro ramblings page
Yes, it's changed since the first version of the MiSTery core: I've added more standardised support for loading and saving configs to the framework, and made its behaviour consistent between cores. For those cores which support config files, the relevant menu can be found by opening the OSD then pressing cursor right. Hope that helps.
-
Sorry for the delay, I have only one retro desk for all machines.. The key's you mention don't work. I don't understand the grid, so here is a screenshot. When PS/2 mouse/keyboard is plugged in the I have none left working on the C64 keyboard / PS2 keyboard mouse.. Standalone it the minimig core works perfectly and the C64 core does not wait for keys to be released ant the interface is usable.
No need to apologise! But that's a very interesting result!
The keyboard grid corresponds to the C64 keyboard matrix (http://sta.c64.org/cbm64kbdlay.html) but it's transposed, so rows in the matrix become columns in the grid and vice versa. Your non-working keys should be the rightmost column of the grid, so I was expecting to see that column "stuck" in the "on" state - but it's not. Instead you have the bottom row "stuck" - and that's the reason for the "Waiting for keys released" message.
That row corresponds to the keys: crsr up/down, left shift, X, V, N, comma, slash (and run/stop).
Do any of those keys cause a response in the grid? And does the Enter key toggle the first block in the second row?
Do you have joysticks connected to the C64? (In your screenshot the test is reporting that 2nd and 3rd fire buttons are pressed in both ports) And do you have a IEC device connected to the C64 or the Chameleon?
-
I noticed on the right you can test the ports like joystick they test out OK. The keyboard tests out ok mostly, but the one and two key not and also the key combination to bring up the minimig menu does not show. However this C64 keyboard works fine standalone or with the TCV2.
Interesting - are any of the squares in the keyboard grid permanently toggled? (I was expecting there to be either a complete row or column that was compromised.)
If 1, 2 and <- don't work, do the Commodore Key, Control, Space, Run/Stop and Q in particular also fail? (Those are the other five keys that have a bit in common with 1, 2 and <-)
-
I don't see in the wiki how the hardware test should run, but this is the only thing I get with the green bar from left to right.
Interestingly, the hardware test core has been developed a bit more since the binary release that's downloadable from the Wiki - the current source on github does support reading the C64 keyboard matrix, so it might be interesting to try it on your V1.
I just compiled the current source (for V1 - don't try this on V2 hardware!) and attached the result.
(If anyone specially wants a version for V2 hardware too just let me know.)
-
The HW test core does not test the bridge to the C64, which is where I'd suspect the fault. In any case, if it's a hardware fault, it can of course be repaired.
Jens
Hmm - maybe my memory's playing tricks on me - I thought the HW test core scanned the C64 keyboard matrix and joystick ports?
-
Definitely don't toss it out!
Have you tried updating the core and menu firmware (using chaco over a USB connection to a PC)?
Have you tried the Hardware Test core or any of the 3rd-party cores from http://wiki.icomp.de/wiki/Chameleon#Cores ?
(You can launch a core using Chaco - so not being able to access the Chameleon's built-in menu shouldn't prevent further testing.)
-
Hello 
I created a Harddrive image with two partitions (2x512MB). This hd image works very well on the MiST FPGA and also on the TC64. The same settings are in the Mistery- core on both devices (STE, 4MB, TOS 1.62). The Fantastic STe Demo "Sea of Color by Dead Hackers Society" works very well on the MiST Mistery core. On the TC64 Mistery it gets stuck in the middle of the demo with four bombs - why? Best regards, Paul
Thanks for the bug report. I'll look into it. It might be related to disk performance since I don't have space in the supporting firmware to build a full hardfile index, so seeks can be somewhat slower than on MiST or a real hard disk.
Does the audio work for you? I just tried the demo here, and I don't get music, and after the first couple of scenes the video's screwed up too.
-
That really makes me wonder... aren't those adapters completely passive?
As far as I know they are completely passive, but they do introduce a second set of potentially dodgy contacts with unknown resistance. I'm sure they don't do the signal integrity any favours!
-
Do any of the 32Gb cards work with other cores?
Also, are they Micro SD cards in an adapter? If so can you try with a different adapter?
(I have several adapters: One works fine on my MiST board but won't work on my TC64v2. One which works fine on my TC64v2 won't work on my MiST!)
-
I don't know what's causing this, but I don't think it's a coincidence that you're also having trouble with the NES core. The menu freezing on NES is very likely due to the core getting stuck during SD card access.
Are you using the cartridge attached to a C64? Can you find a PS/2 keyboard from somewhere (or a CDTV controller) and try it in standalone mode?
-
Thanks for the reply Jens 
I asked about it because many cores have this option. A solution would also be a scart- RGB cable for a CRT monitor or TV.
Then 50Hz would also be possible?
Changing disks in "Floppy A" will not work. But I can change the floppy disk if I use the "Floppy B". Is it a bug?
See attachment for testing. The loading times of the floppy disks are long.
Display More
The Atari ST can run at PAL or NTSC refresh rates, but unlike the Amiga the default mode isn't set by hardware but by ROM version - so if you use a US version of TOS then (when set to Colour mode) the emulated ST should start up in a 60Hz mode. (In Mono mode you get the same high-resolution monochrome screenmode whichever ROM version you use.)
The problem with using an RGB to SCART cable with a CRT is the need to ensure that a VGA-scanrate signal never goes down the cable, since it's possible to damage CRTs by feeding them unexpected scanrates. That said, an RGB to SCART cable should already work when the MiSTery core's scandoubler is disabled (and when the core's set to Colour mode, of course) - but it's safest to use it with an LCD TV.
Thanks for spotting the floppy disk diskchange bug - I'll fix that very soon.
-
On "Kirby's Adventure" which supports SRAM, when I mount SRAM, game freezes.
And when I try to open emulator's menu, it also freezes.
I can confirm that Kirby's Adventure freezes when you load the SRAM file - but it's OK after a reset from the menu.
If the menu won't open (and if selecting Write SRAM causes the menu to lock up) that sounds like it could be SD-card related.
(Trying another SD card is usually the first step in troubleshooting these cores. I have a MiST, a V1 Chameleon, a V2 Chameleon and a few other random boards - and I've found occasional cards that will refuse to work on one device but be fine on all the others. Micro-SD-to-full-size-SD adapters can be a source of trouble, too.)
-
Unfortunately the DB9 joystick ports on the TC64's dock are strictly unidirectional, so it's not possible to read more than two buttons on a CD32 pad connected to the docking station.
(The mention of CD32 gamepads in the on-screen menu is something I should probably hide on TC64 - though in theory I could emulate a CD32 pad using either the keyboard or the CDTV controller. The gamepad emulation is implemented on MiST when using USB gamepads - but real pads on the DB9 ports aren't supported there either.)
-
Thank You very much.
Could You tell me - step by step - how can I create this 8kb .SAV file, please?
Here's a blank save file (zipped because the forum won't allow me to upload it otherwise) - copy the blank.sav file to the SD card, and rename it to something suitable. (You need a different .sav file for each game which supports non-volatile RAM.)
-
Sorry, I've been a bit preoccupied with real-world stuff.
To use save RAM, you need to create an empty file on the SD card, 8kb in size, with the file extension ".SAV".
Load your ROM, then select "Mount SRAM" from the menu and choose your .SAV file.
The "Write SRAM" menu item will write the SRAM to the previously-mounted .SAV file.
(Just in case it's not clear, the .SAV files imitate the non-volatile memory found in some cartridges for saving game progress - they're not intended to be anything like an emulator's save state - so for games which didn't contain non-volatile storage they won't do anything.)
