VICE/1571 - C64 hängt beim IEC-Bus Handshake

Es gibt 31 Antworten in diesem Thema, welches 4.385 mal aufgerufen wurde. Der letzte Beitrag (24. Dezember 2020 um 21:57) ist von darkvision.

  • whatever it takes to read a data block from the disk with standard b-r/u1 instructions

    Don't confuse B-R and U1, they are distinct commands with different purposes.

    10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    20 forj=1to5:printchr$(rnd(1)*16+70);:next
    30 printint(rnd(1)*328)-217

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • I guess he knows what he is doing... and this was just an example that you can use any commands you want... even u0>m1 or m0 or xr:dos1581.bin ;)

    I'm using u1 and u2 in my drivers... i guess he is doing also...

  • This is not a surprise. It's easy to confuse VICE while changing drive types, etc. while it is already running. I end up making many shortcuts with different configurations for testing to avoid this.

    Consider that what you are doing is unplugging/plugging in drives while the computers is "ON" which you would never do. :)

    --

    Peter Rittwage

    C64 Preservation Project

    Bitte melde dich an, um diesen Link zu sehen.

    NIBTools

    Bitte melde dich an, um diesen Link zu sehen.

  • While that is true, VICE has no option to do configuration via UI before power on. You have to use command line options to the exe either naming configuration file or change the configuration via command line options. Not really good.

    ---
    Meine Github-Projekte: Bitte melde dich an, um diesen Link zu sehen. Vice 3.2 Improved: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II / Ultimate 64 Firmware Releases: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II Update instructions: Bitte melde dich an, um diesen Link zu sehen.

  • Hier noch was Sinnvolleres zum Thema. Leider zu spät zum editieren.

    Zitat von Roberto Muscedere

    I'm going to look into this in the next month or so. Work gets busy around this time, but I've made some changes to the CPU tracing in the drives so I can closely see what is going on.

    Bitte melde dich an, um diesen Link zu sehen.

  • Hört sich erstmal gut an. Wenn man es wie r.cade sieht, dann darf man auch im laufenden VICE kein neues Laufwerk "anschließen". Das alles geht aber... nur Laufwerk Bitte melde dich an, um diesen Link zu sehen. lässt sich nicht von 1581 auf 1571 wechseln. Das ist zu spezifisch als das es so gewollt wäre...

    Ich wechsle aktuell nur Bitte melde dich an, um diesen Link zu sehen. oder Bitte melde dich an, um diesen Link zu sehen.... da hab ich dann keine Probleme...

    Mal sehen was draus wird...

  • Wieso das? Mit Bitte melde dich an, um diesen Link zu sehen. ist es kein Problem, am echten C64 ein Laufwerk im Betrieb "anzuschließen" - zumindest von der Wirkung her.

    Have das Ding zwar nicht, aber für die Feststellung muss man es auch nicht haben. Mit so einen Teil geht das natürlich am echten C64, dass man am seriellen Bus Geräte "wechselt" (durch Umschalten), ohne den CIA zu schrotten.

    ---
    Meine Github-Projekte: Bitte melde dich an, um diesen Link zu sehen. Vice 3.2 Improved: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II / Ultimate 64 Firmware Releases: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II Update instructions: Bitte melde dich an, um diesen Link zu sehen.

    Einmal editiert, zuletzt von markusC64 (21. Dezember 2020 um 21:18)

  • Also geht es nur darum das VICE diese Art von Hardware emuliert... ich gehe aber nach wie vor von einem Timing-Bug aus, denn für Bitte melde dich an, um diesen Link zu sehen./Bitte melde dich an, um diesen Link zu sehen. gibt es eine Sonderbehandlung. Wenn das behoben ist kann VICE Laufwerke wechseln wie mit so einer "Weiche".

    Es geht ja jetzt schon, nur nicht für diese spezielle Kombi...

  • Understood - i came in late to the thread and took notice of the changes you made to test the issue. My err.

    No problem, it is interesting to see that other developers have also developed drivers without TurboDOS.

    If you are interested in extending the drivers, the source code for my drivers is freely available Bitte melde dich an, um diesen Link zu sehen.. However, the comments in the source code are in German, but label names are in english.

    Files with a -FD* prefix are for the TurboDOS-free drivers, -TD* is for TurboDOS. The -D3* files are the generic driver routines.

    There is also a final version of the TurboDOS-free MegaPatch... too bad i could not test it with your boot disk, since there was no RAM expansion supported. If you want to give it a try: Have a look Bitte melde dich an, um diesen Link zu sehen..

    Could it be possible that your drivers for 1581 do not support disk name switching? By default the disk name is located at offset $90 on a 1541/1571 disk. If you read a block 40/0 from a 1581 disk you must switch the disk name from byte $04 to $90, or the disk name will be empty. See the screenshots attached. DeskTop 2.x expects the disk name at offset $90. If you write the block back to disk you must switch back the disk name.

    I'm using a routine called ":SwapDskNamData" to do the job. Have a look Bitte melde dich an, um diesen Link zu sehen. and Bitte melde dich an, um diesen Link zu sehen..

    P.S. I have tested your boot disk using VICE. When i create a new disk image using VICE the disk name with your 1581 disk driver will be empty. If you set a new disk name like "BADNAME" DESKTOP will just change the content at offset $90. The driver must fix that. Same for a NativeMode disk driver.