Herzlich willkommen in unserem Gästebuch!

Zum Eintragen hier klicken.

Zeige Einträge 61 bis 72 von 245

Seite: [«] [[4[5(6) [7[8[9[] [»]

Name Kommentar

George Kirkhams E-Mail Adresse s IP angucken


erstellt am 20. Januar 2021 um 4:42 Uhr MEZ   Eintrag löschen  Kommentar hinzufügen  Eintrag bearbeiten
Hi Georg

Apologies, I can't work out how reply to your message below so I thought I'd just repost.

It's great to hear this is something you may look at doing at some point in the future. fröhlich

Yes the CPU is a standard WDC 65C02. A good article listing the additional instructions is:

http://6502.org/tutorials/65c02opcodes.html#3

Also my channel URL was incorrect previously - the correct one showing some of my Commander X16 work:

https://www.youtube.com/channel/UC7ittPQW-Mno7GgiY6pmTeg

Let me know if I can be of any assistance or you need anything from me. fröhlich

Best regards,

George







Kommentar von Endurion:
Hi,

Thanks for the donation!
I'm currently working out the issues with the new addressing modes. May take a day or two to have it up and running.

We can continue the messages via email. Might be easier fröhlich

If you have some sample code using the new opcodes/addressing modes and the assembled binary for comparison, that might be useful.

We'll be in contact!
Georg


George Kirkhams E-Mail Adresse s IP angucken


erstellt am 18. Januar 2021 um 10:38 Uhr MEZ   Eintrag löschen  Kommentar hinzufügen  Eintrag bearbeiten
Hi Georg


I just wanted to say I've been using your C64 Studio product for a while now and really enjoy it and think it's a very useful tool. However I've been using it to develop assembly language programs for a new 8 bit computer - the Commander X16. Examples of my work can be found here:

https://www.youtube.com/channel/UC7ittPQW-Mno

It's still in the advanced prototype phase and Michael Steil has produced an emulator for it. More details can be found here:

https://www.commanderx16.com/

The heart of the machine is a WD 65C02. I was wondering if you could extend your C64 Studio to cover the additional opcodes, e.g. PLY/PHY, PLX/PHX, INCA, BRA etc and the new addressing modes. I have currently implemented a few using Macros but it would be great if it could natively compile them.

Anyway completely understand if you're busy with other projects but thought I would ask.

Keep up the great work!

Regards,

George



Kommentar von Endurion:
First of all, thanks for the feedback! fröhlich
Interesting regarding the new opcodes.

I have only half assed support for other processors, but that could be a good exercise. However I can't promise anything, nor how fast I could make it happen.

Especially adding new addressing modes is not completely trivial.
I'll think about it fröhlich

Is there a full list of the supported opcodes? On a first quick glance I couldn't find it. Ah, it's a generic WD 65C02. Fine then fröhlich

The BASIC could actually work already with the new BASIC dialect support. You can add a new text file listing all BASIC commands and their one or two byte token values.

Julians E-Mail Adresse s IP angucken


erstellt am 23. Dezember 2020 um 12:25 Uhr MEZ   Eintrag löschen  Kommentar hinzufügen  Eintrag bearbeiten
(Antwort auf den letzten Kommentar)
Bei mir steht als Startadresse $0884 und als Ende $08Ax, da stimmen die 43 also, zumindest in etwa, aber ich nutze noch die Version 6.4. Vielleicht sollte ich mal updaten ...

Abgesehen davon, eine kleine Anregung: Wenn man keinen Step setzt, wird ja automatisch 1 genommen. Wie wäre es, wenn automatisch -1 genommen wird, wenn der Startwert größer als der Endwert ist? Man könnte nebenbei noch eine Warnung angeben, aber eben keinen Fehler.

Julians E-Mail Adresse s IP angucken


erstellt am 22. Dezember 2020 um 17:49 Uhr MEZ   Eintrag löschen  Kommentar hinzufügen  Eintrag bearbeiten
Hallo,

ich hätte da eine Frage:

!for i = 3 to 0 step -1
!for j = 0 to 39 step 1
!byte (i * 40) + j
!end
!end

Wenn ich mir das so angucke, würde ich sagen, dass das 4 * 40 Bytes sein müssten. Tatsächlich sind es aber nur 43 und absurderweise verbrauchen die Lines mit !end jeweils 3 Bytes. Da ist irgendwas schiefgegangen ... oder ist das so richtig?


Kommentar von Endurion:
Da ist leider die Anzeige mit den Bytes pro Zeile nicht korrekt. Nehme ich direkt als Bug auf, danke!

Wenn du auf die Adressen der beiden !ends guckst, werden dann insgesamt doch die erwarteten 160 Bytes erzeugt.

Mit dem Aufaddieren der Bytes einer Zeile, die mehrfach verwendet wird, habe ich offenbar doch noch Probleme fröhlich


Julians E-Mail Adresse s IP angucken


erstellt am 20. Dezember 2020 um 18:26 Uhr MEZ   Eintrag löschen  Kommentar hinzufügen  Eintrag bearbeiten
Hallo,

ein kleines Problem hätte ich dann doch noch:

Da steht "[...] 607 bytes [...] 161 bytes [...]" - zweimal Bytes! Dabei meinen die Ersten die Zeichen und die zweiten die Bytes beim assembleten Programm. Es wäre praktisch, wenn du die ersten Bytes durch "characters" oder so ersetzen könntest, ich war gerade sehr schockiert, dass mein Programm 600 und nicht 200 Bytes brauch.

Gruß
Julian


Kommentar von Endurion:
Danke für den Tipp, wird direkt umgesetzt fröhlich


s IP angucken


erstellt am 17. Dezember 2020 um 11:02 Uhr MEZ   Eintrag löschen  Kommentar hinzufügen  Eintrag bearbeiten
Hi Georg,

I have come across a NEW C64 MUSIC TRACKER named: DEFLEMASK, which is great but INTI AND PLAY ADDRESS of the .SID files:

Load range: $1006-$6951
Init address: $1103
Play address: $1006

IS Different to HVSC FILES, which typically :

Load range: $1000-$1C4E
Init address: $1000
Play address: $1003

i am having trouble in C64 STUDIO, the code compiles good but the music program conflicts with my .asm code making garbled sprites and music does not play properly.

HOW do i relocate the INIT AND PLAY ADDRESS of the files so that they conflict with other code in c64 studio?

thnks

Syed



Kommentar von Endurion:
Hi Syed,

Relocating code is not trivial. There are a whole bunch of tools helping with that, the keyword being "relocator".

I have never attempted to do so myself, but you can try a few:
https://csdb.dk/search/?seinsel=all&search=relocator&Go.x=0&Go.y=0



Syed Rizvis E-Mail Adresse s IP angucken


erstellt am 12. Dezember 2020 um 2:26 Uhr MEZ   Eintrag löschen  Kommentar hinzufügen  Eintrag bearbeiten
Hi Georg,

a Desktop ICON, C64 STUDIO, does not want to load. I need to get into the directory where the .exe file is located in order for it to load.

please help!

thnks
Syed



System.IO.FileNotFoundException: Could not load file or assembly 'WeifenLuo.WinFormsUI.Docking, Version=3.0.4.0, Culture=neutral, PublicKeyToken=5cded1a1a0a7b481' or one of its dependencies. The system cannot find the file specified.
File name: 'WeifenLuo.WinFormsUI.Docking, Version=3.0.4.0, Culture=neutral, PublicKeyToken=5cded1a1a0a7b481'
at C64Studio.MainForm..ctor(String[] args)
at C64Studio.Program.Main(String[] args)

WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLMSoftwareMicrosoftFusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLMSoftwareMicrosoftFusion!EnableLog].



Kommentar von Endurion:
Thanks for the info, looks like I forgot to copy the new DockPanel dll in the release folder. Sorry!

New archive is uploaded!


s IP angucken


erstellt am 28. November 2020 um 15:52 Uhr MEZ   Eintrag löschen  Kommentar hinzufügen  Eintrag bearbeiten
Ich hoffe wirklich, ich nerve nicht, hier wäre nämlich nochmal eine Anregung:
Es wäre sehr praktisch, könnte man einfach den Cursor an das Ende einer Zeile setzen und dann unten neben der Zeile und Spalte den OP-Code der Zeile ablesen. Momentan muss ich ständig bei https://www.retro-programming.de/programming/nachschlagewerk/mnemonics/# mit Strg+F nachgucken, wenn ich für selbstmodifizierenden Code einen OP-Code nachgucken muss, wenn ich gerade ADC mit X indiziert habe, dann dauert das auch einen Moment.
Außerdem weiß ich nicht, ob sowas in der Art nicht schon standardmäßig existiert, aber wäre es nicht unheimlich praktisch, könnte man z.B.
LDA [ADC (),Y]
oder
LDA #[ADC (),Y]
schreiben und könnte damit den in eckigen Klammern schemenhaft angegebenen OP-Code in den Akku laden? Das würde nicht nur Zeit sparen, sondern wäre auch ohne Kommentare lesbarer.


Kommentar von Endurion:
Bei dem Debugger-Problem bin ich schon dran, aber ich hab's noch nicht ganz eingekreist. Scheint auf jeden Fall eine Art Racing-Condition zu sein. Wenn ich Debug-Logs aktiviere, verändert sich das Verhalten. fröhlich

Als Nachschlagewerk ist übrigens das AAY64 eingebaut, in der Hilfe-Seite ganz unten. Da sind auch alle Mnemonics drin aufgelistet. Noch nicht ganz, was du möchtest, aber schon mal einfacher (bzw. Cursor auf Mnemonic setzen und F1 drücken)

Das andere sind schon sehr spezifische Erweiterungen, das mit den eckigen Klammern könnte aber sogar verträglich funktionieren.


s IP angucken


erstellt am 26. November 2020 um 8:51 Uhr MEZ   Eintrag löschen  Kommentar hinzufügen  Eintrag bearbeiten
Wieder zu deinem letzten Kommentar: Ja, man müsste natürlich für ein richtiges Bild, wie es wirklich von VICE kommen würde, Scanline-IRQs emulieren, aber das meine ich nicht, was ich gerne hätte, wäre die Option, sich den BS-Speicher im aktuellen Zustand anzusehen, so, wie es entstehen würde, würde die CPU völlig pausieren, nur ohne den VIC, dadurch könnte man sich Sachen ansehen, bevor sie über die Scanline laufen, wenn man z.B. irgendwelche Scanline-IRQs hat, die Sprites multiplexen sollen oder wenn sich der Bildschirm schneller aufbauen soll, als der VIC da mit der Scanline drüberfahren kann. Für sowas würde es ja momentan reichen, bei Debug Memory die entsprechenden Daten, die der VIC lesen würde, rauszukopieren und dann an einen zweiten virtuellen VIC zu schicken. Oder sehe ich das falsch?


Kommentar von Endurion:
Ja, das klingt alles gut und sinnvoll. Das geht schon ziemlich in die Richtung des eigenen Emulators.

Vielleicht könnte ich dazu wirklich den im Code vorhandenen, extrem rudimentären Tiny64 verwenden. Der kann im Moment eigentlich nur die CPU emulieren, aber so halbwegs das Bild daraus zu generieren, wäre wohl eine interessante Aufgabe. Ist aber auch wirklich nicht ohne fröhlich


s IP angucken


erstellt am 25. November 2020 um 12:26 Uhr MEZ   Eintrag löschen  Kommentar hinzufügen  Eintrag bearbeiten
Irgendwie ist mein alter Kommentar weg, ich hatte mich da nochmal auf deinen letzten Kommentar bezogen, denn es würde nicht allein reichen, alles anzuhalten, wenn man sehen will, wie sich gerade ein Bild aufbaut, dazu wäre es nötig, sich den Bildschirmspeicher im aktuellen RAM so angucken zu können, wie er letztlich auf dem BS zu sehen wäre, also im Grunde Debug Memory, nur dass jede Zeile 40 Bytes enthält.


Kommentar von Endurion:
Ja, das wären alles so Dinge, die ich viel besser machen könnte, wenn die Schnittstelle einfacher wäre fröhlich

Den aktuellen Bildschirm aus dem Speicherinhalt zusammenzusetzen ist ja nur bedingt machbar. Das funktioniert bei einfachen Sachen, aber sobald da VIC-Umschaltungen bei bestimmten Zeilen erfolgen, muss man da eine Historie mitziehen.

Ach Mann, ich möchte einen Emulator in C# drin haben, wo ich direkt alles anpacken kann.


Julians E-Mail Adresse s IP angucken


erstellt am 24. November 2020 um 13:56 Uhr MEZ   Eintrag löschen  Kommentar hinzufügen  Eintrag bearbeiten
Uuuuuund .... jetzt ist er wieder da, der Fehler. Mein Programm ist sowas wie

lda einHaufenDaten, X
sta $02 ;break

;Debug
ldy $02 ;break
;Debug

inx ;break

in einer Schleife und ich konnte im Y-Register andere Werte als bei Debug Memory feststellen. Ich weiß nicht, was es ausgelöst hat, und es ist tatsächlich mitten beim Debuggen passiert, ich hatte gerade damit angefangen, mehrere Fenster zu verwenden. Es änderte sich einfach nichts mehr, beim Öffnen eines neuen Fensters sah man dann zwar den korrekten Status, wobei die Bytes, die sich geändert hatten, nicht rot markiert waren.

Anbei noch eine kleine Anregung: Wie wäre es mit einem Debug-Fenster, bei dem man sehen kann, was der VIC ausspucken würde, würden sich keine Register ändern? Momentan kann man leider während der Untersuchung eines Breakpoints sich den Bildschirm nicht angucken, was eventuell wegen der Scanline auch nicht zu viel Sinn machen dürfte. Ich würde das sicherlich öfters nutzen.


Kommentar von Endurion:
Da ist ja wirklich etwas im Argen, ich gucke mal, was ich da gedreht habe.
Zum Glück habe ich das schon im GIT drin und kann die Historie des Debuggers prüfen.

Zu der Ansicht: Ja, das ist extrem unpraktisch, dass VICE da hängt. Zumindest die alte Version, ich meine, bei der GTK-Version tritt das nicht mehr auf.

Auf ganz lange Sicht möchte ich den Emulator ja integriert haben, dann verschwinden eine ganze Reihe Probleme automatisch. Im Moment steuere ich ja nur den externen VICE.


Julians E-Mail Adresse s IP angucken


erstellt am 24. November 2020 um 13:41 Uhr MEZ   Eintrag löschen  Kommentar hinzufügen  Eintrag bearbeiten
Tut mir leid, das Problem mit Debug Memory konnte ich leider nicht erneut erzeugen. Ich habe keinen Plan, was es verursacht hat. Allerdings konnte ich einen anderen Bug finden, bei dem ich nicht ganz weiß, ob er sich lösen lässt: Wenn man nicht auf "Stop Debugging" drückt, sondern einfach VICE schließt und dann erneut den Debugger startet, öffnet sich ein VICE-Fenster bei den Breakpoints. Ich weiß nicht, ob Sie (oder dürfen wir sie duzen? Ich bin mir da nie so ganz sicher) davon schon wissen und ob man einfach nicht VICE schließen sollte, denn wozu ist dann der Knopf? ¯_(ツzwinker_/¯


Kommentar von Endurion:
Kann man gerne duzen fröhlich

Das muss ich mal nachstellen, was da schief geht. Eigentlich sollte auf das Gleiche rauskommen.

VICE macht dann den Monitor auf, wenn die Remote-Verbindung nicht aufgebaut wurde. Dann steht vermutlich etwas wie "Debug Attempt failed" oder so im Output Display.

Seite: [«] [[4[5(6) [7[8[9[] [»]

Administration


Gästebuch Hauptseite | Meine Hauptseite

powered by unzes gb 3.1.1
© 2001 - 2003 by Daniel Köhler