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.
Please understand that you need to create an account to be able to post, guest posting was disabled as an anti spam measure.
First advice is a good clean of the edge connector of that A500 with Isopropyl alcohol.
If it is specific mouse/joystick direction that give trouble it might be that the input multiplexer chip of that machine has developed an issue. We have seen that a few times especially in combination with ECSv2/3/4 flicker-fixers where that chip doesn't output a valid signal and causes mouse issues. That would be U15 a 74ls157. Can be replaced with a modern 74HCT157.
For hires your pixel clock should be half of the Amiga xtal. So half of 28.6 which is 14.3 Mhz. This will give you about 900 pixels horizontal at 15 Khz. Of those 900 about 150 should be sync (10us of 63u total if you follow NTSC timing which I assume you do at 60 Hz). Vertical you need about 20 sync lines to make the monitor happy.
You also need some front and back porches that blank out pixels around the sync lines. On 60 Hz vertical you won't get 256 lines but only about 200, for 256 you need to go down to 50 Hz vertical refresh (following PAL timing).
Correct depending on the audio output the mono signal will come only from the left or right channel when stereo mode is selected and you play a mono song, the other side will be silent as that SID isn't receiving any data.
This might not be the tool's fault. There is an item on my todo list to check the reset generation. If the tool is using the CPU "RESET" instruction to do the restart it might explain the hanging.
Yes what you missed is the "audio output" settings. This allows you to let one SID on the left channel and the other on the right channel. If you then select "Mono SID 1" or "Mono SID 2" in the menu you quoted both SIDs will play the same sound. The only difference between mono 1 and mono 2 is which SID is used for reading.
What I notice is the lack recognizable characters (from character ROM). With a ram failure you would still see characters in that screen-mode just random ones. I agree with Jens that the first place to start searching is the PLA either the chip itself or its connections.
tc64 is not suited as a diagnostics tool. It uses many features simultaneously, but at the same time replaces cpu, rom and memory.
Can't the SDRAM bé clocked at 133MHz to match the 1:2 ratio with the CPU like with 60Mhz.
We did indeed test the memory and the drivers at 133Mhz successfully during the validation of the hardware/board design. The challenge is making the CPU happy with the returned data and and making sure it arrives on time. Now the faster you run the clocks the trickier this gets. At those suggested frequencies you get into margins of just a few nanoseconds for things to arrive on time. If you are impressed by zeros a nanoS is 0.000000001 seconds. And that must be correct for all 4 memory banks simultaneously (to give you this amazing 254 MiByte fastram that the card offers). With a CPU that thinks 15 nSec is already fast according to its datasheet (to get that into Mhz do 1000/15 is only 66 not this magic 133 Mhz so much desired, so yeah.. there you go technical details 
Now our top priority is stability of the product first, insane speed comes second (or maybe third and the other features second.. dunno something like that
So we are currently working on the IDE speeder (making writes faster), the software tooling and bugfixes.
Only then we can look at some improvements in memory performance and this might indeed be one of areas we can try to improve on. We know performance is important too, but preferably without causing instability as that is a bad trade-off.
Just a note for others - before you buy a speed upgrade for your 1240/1260 - THOROUGHLY test stability. I bought a 33 MHz to 40 MHz upgrade for my 68040, and thought it was stable -- but it was not :).
We are aware of reported issues with 68040s running at 40 Mhz. Although not guaranteed (as it depends on the CPU ofc), but it is likely future updates of the firmware will improve the stability of this specific speed setting.
No for supercpu it is mostly the lack of software that really need it compared to the required development time.
For faster executing (the main draw of supercpu) we have the much more compatible turbo mode which offers similar speedups, but supports illegal opcodes and doesn't require adjusted kernal routines for IEC to work.
Correct those two connectors are wired identically.
Yes the card works without the fan. It will likely complain by flashing the red LED with the "temperature" error code (mostly off short blink).
Be careful with the temperature sensor without the cooler installed it sits sticking out of the PCB unprotected.
If you do this I recommend having something else that moves the air. During development I had a cheap standard PC fan pointed at the CPU to blow some cool air over it.
The instructions imply you just press F and the menu appears, like on every other option, so it is a surprise and looks like something has gone wrong when I'm suddenly asked for a password that is NOT referred to until the very bottom of the Factory Reset section, and then in a smaller font so that it actually looks like faulty HTML code or a rendering problem.
Yeah ideally the menu should maybe only ask for the password when you do something dangerous (voltages). As most of the F menu is "safe". But in the flow of the software it was easier to protect the top-level menu with the password instead of each individual entry. As you might have read in other threads the MCU (the device doing the menu magic) is very full. So there was/is very little space for additional help text.
That said, you immediately concluding something is wrong when a device is asking for a password, that is something I can't help with. And the password is public (though kinda hidden on purpose). As we don't want to lock people out completely, but it shouldn't be accessed by accident. For example when the serial program is sending random data from a file (or a wrong copy/paste etc) and the text contains a F it is nice to know you don't immediately fry 30 year old chips that are no longer made. Same if something falls on the keyboard (remember cats LOVE keyboards) and the terminal is open. Again safe.
You indeed have to load an ROM image. The menu does not contain a copy of Simon Basic.
I've written the request down, for if we ever have other reason to update the firmware I will not forget to look into it.
At the moment however other projects definitely have priority like 1260 and the flicker-fixers. And with only 300 bytes remaining, even if I do have time it will be tricky.... sorry, using the serial console is the best we can offer for now. Thanks for the improvement idea anyway, I guess
Reducing the number of kernal versions won't really help as that is eeprom storage area (as it can be updated) and the space restriction is in code area. I'm sure randomly choosing features to drop will upset at least one other customer somewhere. Also not fair as the product were sold with these features, we can't just drop them without a very good reason IMHO.
If I read my listing correctly we are at $1EB0 (ish) and the code space ends at $1FFF. So maybe 300 bytes give or take, that isn't much space indeed to add a new menu item and the code to handle it.
Another question, can the video port be used in same time as the VGA?
Yes, you can use both at the same time. Well at least for standard Amiga screen-modes. Special modes like Graffiti and A2024 are only correctly displayed on the VGA.
Video port will still provide output for a classic RGB monitor as we emulate the Denise. That said genlock hardware might not be compatible with the emulation.
pin 1 to 9 same as you have for V2/V3
pin 10 monitor SDA goes to VGA p12
pin 11 monitor SCL goes to VGA p15
pin 12 monitor power goes to VGA p9 to power EEPROM in the monitor
