Posts by SID-6581

OK, finally i got my PS/2 Mouse to work. Use in GEOS the Keycombination "ALT+I" (on a real C64 keyboard: Commodore+I)to change the input device.

So neither the dockingstation nor the TC64 could be damaged if the joystick or the mouse are connected or removed while the system is running?

And does this also apply to a real C64? I always thought that the connection or the removal of plug connections should only be made when devices are switched off.

So should I only connect the mouse after the TC64 has started up so that I can use it under GEOS? Or can a mouse on the docking station not be used? I didn't really figure out the last few answers.

Unfortunately, it doesn't help if I move the mouse or press the mouse buttons on the black screen. It just can't go on. Have you already tried to imitate that?

Quote from Tobias

I am not sure i understand what you are saying. The C64 core checks if any Keys are being held down at startup and pauses after the bootloader if so. A connected Amiga Mouse could very well cause the same problem - thats just how it works.

No key is helt down. Just connected an amiga mouse to port 1 of dockingstation v2 and turned the power on. TC64V1 wont start. You just see a black screen with the vga debug overlay. Disconnected the mouse and TC64V1 runs fine. Tried it with two amiga mice. PS/2 mouse was disconnected from breakout cable.

In the test program, the mouse (Port1) was recognized without errors when the TC64V1 was connected to the dockingstation v2.

The error persisted in GEOS even when the TC64V1 was disconnected to the dockingstation v2

I would like to add that one after the other two Amiga mice connected to port 1 of the dockingstation V2 resulted in the TC64V1 not wanting to start up at all. Even if the keyboard and mouse were separated from the breakout cable.

Cheers
SID-6581

TC64V1 on docking station V2 with firmware 9k. A PS/2 mouse is connected via the breakout cable. Both, a mouse that had to be connected

via a USB adapter and a mouse with a PS/2 connection, were tried out. Both mice run smoothly under the MinimigAGACore.

Good evening and merry christmas,
I have already tried various GEOS versions. First a 16MB GEOS REU image, then a geos-georam version and finally a completely normal Geos boot disk. The mouse is never recognized correctly. If I configure the mouse in the TC64 menu for port 1, it does not react under GEOS when it is moved. The left mouse button works correctly. If you press the right mouse button, the mouse pointer moves up.

If the mouse is configured for port 2, it does not react to anything.

I separated the joystick from the docking station for the tests.

Since I have the same problem with two mice, I think it is possible that it could be a problem with the 9k firmware.

Cheers
SID-6581

Quote from Jens

The smallest denominator for the Amiga is a 16-bit chip with IRQ capability. I have pushed the cost for this down a lot with the X-Surf-500, a 100MBit Ethernet card for the ACA500plus. I do see a possibility for a Docking station that lets you use this, which would make MUCH more sense than "anything clock port". Yes, it would cost additional money and yes, this 100MBit Ethernet port would not be usable from the C64 side. However, it would be the only thing that results in a usable system.

If the price was kept within a reasonable range, I would be very interested in such a product for the docking station. I think that this would also be interesting for even more customers, since nowadays the Internet is almost a matter of course for the Amiga. But the MinimigAGACore would have to support the product first.

Oh great, that sounds good.

If you were able to use the "RR-Net MK3" under the MinimigAGACore so that Internet is available under the Workbench, that would be a reason for me to buy the "RR-Net MK3". But the question is whether that would even be possible. Of course, this could only be realized once your schedule allows it.

Hello Alastair, would it be possible to use the RTC of the Turbo Chameleon with the MinimigAGACore under the Amiga Workbench?

Thanks for the good news Tobias. I have to admit that I had to rub my eyes first when I read about the monthly updates.

The Turbo Chameleon would do very well to finally reach the final status after the long years of the beta phase. In any case, I'm already looking forward to the final version of the firmware.

Cheers
SID-6581

P.S: I offer you to help with testing within the scope of my possibilities.

Hello Alastair,

thanks for the new Minimg AGA Core from December 5th, 2020. The above-mentioned read / write errors have now been corrected, even if the Directory Opus Cache is reset from 500000 to 50000. Great work!

I'm also very happy about the new RTG 16-bit support and the 2.5 MB extra fast RAM.

The FDD and HDD drive sounds are especially fun. You get a real Amiga feeling!

A nice Christmas present from you. Thank you!

Cheers

SID-6581

PS: I found a problem with the HDD drive sound. After a reboot of my TC64V1 you can no longer hear the HDD drive sound, although it is still activated in the menu. Only when the drive sound is switched off and then on again in the menu is it reactivated. I don't have the problem with a reset.

Quote from robinsonb5

As it happens, I had already noticed and taken care of the sync inversion with V1 hardware.

I think the problem you're seeing happens with system-friendly games that open a low-res screen?

Also DPaint / PPaint show it too, if you open a 320x256 screen - but are OK if you open a 640x256 screen?

As a temporary workaround, use overscan prefs to set PAL overscan to its minimum width and rightmost position.

Display More

Thanks for the tip. After I edited the overscan, the image is still not displayed in the center of the monitor, but at least the entire PAL screen content is displayed correctly again.

Can the timing problem you suspect while using the TurboKickrom be fixed?

Quote from Jens

THe picture shifting might be caused by a hardware difference between V1/V2 Chameleon hardware. We just today found that the H/V Sync output polarity is not properly documented in the FPGA coder's manual. In short:

V1 hardware outputs the H/V Sync signals inverted

V2 hardware outputs the H/V sync signals non-inverted.

Most monitors don't care, but shift the picture a little. Some monitors might just fail displaying the picture. In order to bring both hardware revisions in line, Alastair should change his toplevel designs to make that difference. Note that this is just an implementation detail of the target hardware that can be easily taken care of in the core- but it should be taken care of, otherwise bug regports might come in totally weird and not reproducable for Alastair.

Display More

Ah... that would explain it.

I must correct myself. I have the left shift in all PAL games, no matter if WHDLoad or NON-WHDLoad.

Quote from robinsonb5

Thanks for taking the time to test this again - it's much appreciated. Half a meg is a *huge* stack - I suspect the root cause of this is going to be something much more subtle. I'm fairly certain it's timing-related, which is why the Turbo KickRom function makes a difference - but in a system that employs burst transfers and cachelines, timing can be affected by something as simple as the load address - so the larger stack could have affected it in that way, rather than because the software actually needs it.

A very interesting approach. Do you think a solution is feasible? Would it be very complex or rather simple?

I found another problem:

When I start NON-WHDLoad games (PAL) like Austerlitz, the picture is shifted to the left. The writing is no longer legible on the left edge. There are no problems with this in WHDLoad games. I'm not talking about the edge of the monitor, but the edge of the image displayed. The folder Devs/Monitors only contains the files PAL, NTSC and Minimig.

After the results of the above tests had not changed with a stack of 100000 for DirectoryOpus, I finally set the stack to 500000. Look at the results:

!!!TurboChipram ON or OFF + TurboKickrom OFF: All three folders are copied without errors. !!!

TurboChipram ON or OFF + TurboKickrom ON: DirectoryOpus no longer hangs, but windows with the error message "AmigaOS 3.1.4.1 has a checksum error in disk block ..." appear while the three folders are being copied.

This result should be taken as proof, that the TurboKickrom leads to checksum errors on the HDF files.

Cheers

SID-6581

Quote from robinsonb5

I don't think the fixes will make any difference to the problems you've seen, but I'm not 100% sure.

I'm still considering how to go about debugging the HDF corruption problem.

You're on V1 hardware, yes? (Asking because I have one SD card here that resolutely refuses to work with Minimig on V2 hardware, even though it's fine on all other platforms, and works from the Chameleon core on V2, too. Very odd!)

Thanks for the information. Yes, I am using a TC64V1. Above I uploaded a photo of the SD card I am using.

Quote from robinsonb5

Thanks, it's all useful data.

Thanks Alastair for the publication of the MinimigAGACore from October 23rd, 2020. Since you have also implemented "CPU bug fixes from Tobiflex and cache improvements from Slingshot", I ask whether this should also have an effect on the above tests, so that I should test again.

Quote from Jens

You're trying to copy large archives with a large program. Not sure what Dopus 4 does in terms of stack, but you might want to try increasing the stack to 100k, just to make sure you're not running into this kind of problem.

I repeated the above tests, setting the DirectoryOpus 4.16 stack to 100000. The result remains the same.

Addition: I tested on a TC64V1 with AmigaOS 3.1.4.1 on a 4GB HDF file as DH0: and another 4GB HDF file as DH1 :.

This is my SD card that I used: