Posts by robinsonb5

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.

    Looks like I have problems with hard disk -support. If I delete something inside HD-image (3 Gb file, 6 x 512 Mb partitions), that file comes back after reboot. Tried same image with Hatari-emulator and there copying and deleting works. Has anybody else had such problems?

    Thanks for the report - I'll look into it. I haven't forgotten about your config file either. Your HDF is in a subdirectory, I think?

    Another issue. Unsure if it's the C16 core or my Chameleon settings. I installed the C16 core, the c16.rom file which I downloaded from the github link given is in the root directory on my SD card as instructed. But when I try boot the core, the monitor screen goes black with the monitor itself (not the chameleon) telling me on the screen "input not supported". I'm guessing it's a video display issue. It's not happening with my other emulator cores. I'm on the latest Chameleon 9p update.

    D64 support is more or less ready, so that will be coming soon.


    It sounds like your monitor doesn't like the 50Hz video output. Most of the other cores default to NTSC mode, so 60Hz rather than 50. Which cores have you tried?

    If you have NES, Megadrive or Master System cores installed, can you try changing them to PAL using the menus, and see if you get the same message?


    Also, just on the offchance that your monitor will tolerate 15KHz PAL video but not the scandoubled, version, try booting hte C16 core and then holding down the leftmost button on the Chameleon cartridge for a second or two - that will toggle the scandoubler on and off.

    The configuration files don't attempt to save mounted floppy images, only hard disk images. Could you send me a copy of the STEHDD.cfg file, please?

    Proto PCBs arrived, assembled and tried on a C64. Surprisingly, my random choice of rows/columns was just right: All numbers and characters do what they're supposed to, shift and space are in the right place, dot and comma work correctly, and I think even the F-keys are right (can't remember the correct graphics symbols). Will send these two adapters to Retroscener tomorrow (all parcel services have already picked up for today).

    Awesome! It may well be that all I need to do for the C16 core is disable the small amount of remapping I'm already doing to make the virtual C16 happy with the C64 keyboard.

    Thanks Alastair, my Fujitsu PS/2 mouse also now works with this patch.

    Glad to hear it - thanks for testing.

    Your idea of being able to save the settings makes a lot of sense, because in the long run it is annoying to reconfigure every time.

    Agreed - I just need to figure out the most memory / ROM-space-efficient way to do it. (It won't be an XML file!)

    The white borders also seem too large to me. Is there a way to reduce them or switch them off completely?

    I don't think so - but I'm not entirely sure. Remember that I didn't write this core, I merely ported it to TC64, and while I don't know much about the Atari ST, I think the border sizes are accurate. (Or at least would be if the scandoubler's disabled and its displayed on a CRT using SCART.)

    It is encouraging that HDD support is planned.

    The upstream core already supports it, so the hard work's already done - I "just" need to add the software side to my framework.


    I also have the C64 keyboard more-or-less working in the Atari core now, so that will be in the next release.

    I've wired up the adapter and ordered a sample PCB, which I will send to Alastair when it's here&assembled

    That's really cool - but I don't have either a C16, Plus4 or a bare keyboard from either. In terms of "real" hardware I only have a C64C and three A500s.


    When you say "change of mapping" are you talking about remapping the differences in key markings / functions between the two types of keyboard? (i.e. cursor keys being four keys on the top row instead of two keys on the bottom right.)

    All useful screenmodes supported by the Minimig RTG will fit comfortably within 2 meg - but if you want to use screen dragging there has to be room for two full screens - hence the default of 4 meg.


    If you're not worried about being able to drag 1024x768 16-bit screens then there's no problem with using 3, or even 2 meg - though I think flipping between multiple screens will be a bit faster if they all fit in the video memory simultaneously.

    The minimig-monitor driver always sets 4MB as standard so that the variable "VIDEOMEMORY" must only be set when you want to have more than 4MB graphics card storage? Have I understood that correctly?

    4 meg is the default, and I don't imagine you'd need more than that.


    It's more likely that you might want to reduce it, to 2 or 3, so that you have more system memory available for the applications you're running.

    Great Alastair,
    after copying the file "minimig.card" from the MinimigUtilities diskette to "SYS:libs/picasso96/", "Beneath a Steel Sky" runs correctly with the driver Picasso96 V3.12.


    I also entered VIDEOMEMORY=4 in the tooltypes of the Minimig monitor driver. However, the error has also been corrected without this setting. How many megabytes of video memory do you think is optimal?

    That's great news! Thanks for testing.


    4 meg is the default, and you'll need that much if you want to use screen dragging with 1024x768 16-bit screens. I'd leave it there unless you find yourself needing a bit of extra free memory for whatever software you're using.


    It was not that easy to find a mechanical keyboard that was PS/2 compatible. During my research I only found the SteelSeries 6Gv2 and the Cherry G80-3000. Both keyboards can also be operated via the USB port. I use the Cherry G80-3000 keyboard on my RPi4 to have no longer stutters in DOS games under RetroPie.

    Espen discovered that WASDKeys keyboards are PS/2 compatible, but only if you use an older firmware. (I did need to adjust the Minimig PS/2 keyboard handling for them to work well, though - the core was emitting a constant stream of LED update events, instead of only sending them when the LED states had changed - and the WASDKeys keyboard firmware doesn't like that!)


    I'm more or less resigned to the fact that if I want a keyboard which has everything I want (ISO, curved ergo layout, tactile switches with minimal pretravel) I'm going to have to build it myself!

    Thank you for your quick feedback!
    But no, that didn't really improved the picture. ;-)

    Hmmm, that's strange. I can reproduce the problem here with the latest core from RetroRamblings, but it goes away if I use the version I posted above.

    Could you try updating the minimig.card driver file from the attached utils disk, please? (This version also allows you to set a VIDEOMEMORY tooltype if you want to devote less memory to the RTG system.)


    If the problem still happens, could you possibly test with an earlier version of P96? (I'm testing with 3.1.0 - I don't have 3.1.2 yet.)

    PS: I use the mechanical keyboard SteelSeries 6Gv2, the joystick VS-7000, the Logitech Z533 2.1 sound system on my TC64V1 and can highly recommend this products to you. Alternatively, the Cherry G80-3000 mechanical keyboard is also ideal.

    It's nice to see a mech keyboard that isn't an ANSI layout. I have an ergo keyboard in ANSI format and while it's OK, it's taught me not to compromise on layout - all my keyboards from now on will be ISO!

    Files

    Good work, Alastair, with this mouse3-core Logitech-mouse responds and works normally :)

    Thanks for testing - hopefully it will still work when I remove the debugging serial output (which will change the timing)!

    So I noticed people having midi ports on the docking station for TC64 V2. I bought the first batch of TC64 V2 docking station. Mine came without midi ports. So the second batch and onwards came with midi ports

    Yeah, the V2 Docking Station has MIDI ports - however it's not specific to the TC64 V2 - a V1 Chameleon in the V2 docking station can also use the MIDI ports. (And for everything but MIDI a V2 Chameleon works fine in a V1 Docking Station.)

    Indeed, there was no other numbers than countdown. On second attempt it stopped to countdown 6 and TTT appeared.

    If the countdown's stopping, then the mouse isn't even allowing the host to talk. That suggests that my attempted initialisation is crashing the mouse!


    I've reworked the init routine completely, and fixed at least one mistake in the process, so I'm hopeful that this version will behave somewhat better. If not, could you repeat the Ctrl-Esc test, please?


    By the time I found out that I had a perfect set of test material, it was already too late and they were all sold - in a bundle with Micromys :-)

    The universe has a strange sense of humour!


    Thanks again for the hints - if we still have trouble once the mouse responds to reset, then it might be worth looking at delays.

    Just tested and Logitech PS/2 mouse didn't respond. OSD counted from 9 Mouse Debug: to 4 Mouse Debug and probably then froze, since there's not much happening in the last 30 minutes :) When it counted to 4 and froze there appeared letters TTT to second row of OSC-screen.

    Thanks, that's really useful. If you're not seeing any numbers (other than the countdown) before the "TTT" appears on screen, then the mouse isn't responding to the reset command - so Jens's first hint about the communication-inhibit time is probably the key.