New hardware - PRGuino (TapeCart SD)

Es gibt 152 Antworten in diesem Thema, welches 43.986 mal aufgerufen wurde. Der letzte Beitrag (10. Dezember 2023 um 19:19) ist von dankaini.

  • Ok, nicht viel kleiner, aber im Schnitt weniger als halb so klein wie C64 Programme, würde ich mal schätzen.

    Die meisten PET/CBMs haben ja nur max. 32kB Speicher, somit sind auch die verfügbaren Programme nicht allzu groß. Vieles ist sogar nur max. 16kB groß, und einzelne .prg Files, also keine Nachlader.

    Daher gut für Tape geeignet, und aufgrund der geringeren Datenmenge durchschnittlich trotz doppelt so langer Ladezeit am Ende schneller geladen als ein Programm am 64er :)

    Ist ähnlich wie beim VC20 oder C16, da kommt man auch recht gut mit einem Tape allein aus. :)

  • Aber für den VC20 müsste es reichen nur den Loader anzupassen, oder?

    Die Adresse des Kassettenpuffers und die Adresse des zum Starten verwendeten Vektors sind ebenfalls fest in der Firmware vorgegeben.

    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.

  • Ok, nicht viel kleiner, aber im Schnitt weniger als halb so klein wie C64 Programme, würde ich mal schätzen.

    Die meisten PET/CBMs haben ja nur max. 32kB Speicher, somit sind auch die verfügbaren Programme nicht allzu groß. Vieles ist sogar nur max. 16kB groß, und einzelne .prg Files, also keine Nachlader.

    Daher gut für Tape geeignet, und aufgrund der geringeren Datenmenge durchschnittlich trotz doppelt so langer Ladezeit am Ende schneller geladen als ein Programm am 64er :)

    Ich will da jetzt nicht drauf rumreiten, es geht mir nur um mein Verständnis.

    Kann ich beim C64 direkt von Kassette einfach mal mehr als 39KB laden?

    Muss man dafür nicht erst mal zusätzliches RAM einblenden und dann nachladen?

    Und Nachlader funktionieren doch mit Tapecart (SD ) sowieso nicht.

    Dewegen hätte ich gedacht: beim PET maximal 31KB und beim C64 max. 39KB.

  • Kann ich beim C64 direkt von Kassette einfach mal mehr als 39KB laden?

    Mit den Kernalroutinen nicht, mit diversen Tape-Turbos und dem Tapecart-Loader schon.

    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.

  • Kann ich beim C64 direkt von Kassette einfach mal mehr als 39KB laden?

    Mit den Kernalroutinen nicht, mit diversen Tape-Turbos und dem Tapecart-Loader schon.

    Achso, da macht das dann der Loader. Alles klar.

  • Da könnten wir jetzt Abhandlungen drüber schreiben, ist aber eigentlich OT.

    Primär geht's ja nicht darum wie groß ein zu ladendes Programm bei dem oder dem System maximal sein darf, sondern darum wie groß diejenigen im Schnitt sind, die ich auch tatsächlich lade/verwende.

    Und da sind von meinem Gefühl her 64er One-Filer im Schnitt mind. doppelt so groß wie PET One-Filer (und das obwohl die PET Programme kaum gepackt sind, wenn ich die durch den Exomizer oder PU-Crunch durchjage, dann umso mehr ;) )

    Aber vielleicht täusche ich mich auch?!

    Ist ja eigentlich wurscht, ein Tapecart für den PET/CBM oder C16 wär denke ich jedenfalls sinnvoll und sicher schnell genug. ;)

    Beim VC20 wäre halt das Problem mit dem nicht durchgängigen Speicher zw. Block 3 und 5, weshalb die größeren Programme welche mehr Speicher nutzen dann nicht mehr in einem File möglich sind. (es sei denn man kann sie so gut packen, dass es sich als One-Filer in Block 0-3 ausgeht?!)

  • Primär geht's ja nicht darum wie groß ein zu ladendes Programm bei dem oder dem System maximal sein darf, sondern darum wie groß diejenigen im Schnitt sind, die ich auch tatsächlich lade/verwende.

    Und da sind von meinem Gefühl her 64er One-Filer im Schnitt mind. doppelt so groß wie PET One-Filer (und das obwohl die PET Programme kaum gepackt sind, wenn ich die durch den Exomizer oder PU-Crunch durchjage, dann umso mehr ;) )

    Aber vielleicht täusche ich mich auch?!

    Ich kenne nicht die typsche Filegröße beim 64er, aber ich habe jede Menge Programme, die 32 KB des CBM 3032 voll ausnutzen. Vor allem Basic-Programme gehen eigentlich oft bis ans Limit. Die 16K-Versionen war nicht sehr verbreitet, deswegen wurde darauf wenig Rücksicht genommen.

    Auch mit meinen eigenen Programmen war ich fast immer am Limits. Aber vielleicht ist das auch nicht repräsentativ.

    Ist ja eigentlich wurscht, ein Tapecart für den PET/CBM oder C16 wär denke ich jedenfalls sinnvoll und sicher schnell genug. ;)

    Beim VC20 wäre halt das Problem mit dem nicht durchgängigen Speicher zw. Block 3 und 5, weshalb die größeren Programme welche mehr Speicher nutzen dann nicht mehr in einem File möglich sind. (es sei denn man kann sie so gut packen, dass es sich als One-Filer in Block 0-3 ausgeht?!)

    Ich habe mich damals überhaupt für Tapecart interessiert, weil ich dachte, man könnte das auf dem PET nutzen. Ein Blick in den Quellcode zeigt dann, dass das Protokoll die Tatsache nutzt, dass die Tape I/O im 6510-Eingangsregister direkt nebeneinander liegen und mit einem Port-Zugriff gelesen werden können.

    Beim PET, wie gesagt, liegen die Bits in unterschiedlichen Registern, müssen ggf. noch mehrfach geschiftet werden. Und an die Firmware wollte ich nicht ran, das war mir zuviel Act

    Der PET kennt auch nicht die automatische Aktivierung eines Tape-Loaders. Das wäre also wohl immer ein zweistufiger Ladevorgang , also erst LOAD dann SYS oder RUN. Ich wüsste jedenfalls nicht, wie das anders gehen sollte. Wobei man den Loader einmalig in den zweiten Tape-Puffer laden und dort immer wieder aktivieren könnte. Aber so schön und bequem wie auf dem 64er wird das nicht werden.

    Und dann müsste noch jemand einen Browser schreiben. Denn ohne ist das TapeCard nicht so prickelnd.

  • Beim VC20 wäre halt das Problem mit dem nicht durchgängigen Speicher zw. Block 3 und 5, weshalb die größeren Programme welche mehr Speicher nutzen dann nicht mehr in einem File möglich sind.

    Da gibts zwei Möglichkeiten:

    1) Einfach über die Lücke drüberladen

    2) Einen Loader basteln, der in Blöcken lädt, denen jeweils eine Länge und Zieladresse vorangestellt ist.

    Der PET kennt auch nicht die automatische Aktivierung eines Tape-Loaders.

    Der C64 genausowenig, aus Sicht des Kernals besteht das zu ladende Programm nur aus zwei Byte, die ab Adresse $03irgendwas abgelegt werden.

    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.

  • Der PET kennt auch nicht die automatische Aktivierung eines Tape-Loaders.

    Der C64 genausowenig, aus Sicht des Kernals besteht das zu ladende Programm nur aus zwei Byte, die ab Adresse $03irgendwas abgelegt werden.

    Ich meinte den Vector auf Adresse $32C,32D, der von den Bootloadern überschrieben wird um nach dem Laden automatisch die Kontrolle zu übernehmen.

    Den gibt es beim PET nicht.

    EDIT: Ich habe gerade mal in die Firmware geschaut. Tapecard macht das anscheinend anders und überschreibt den Vektor an Adresse $302,303 (Basic warm start link). Egal, jedenfalls gibt es diese Vectoren beim PET nicht.

    Wie das beim VC20 aussieht, weiss ich nicht.

    Bitte melde dich an, um diesen Link zu sehen.

    3 Mal editiert, zuletzt von detlef (25. Februar 2020 um 18:40)

  • detlef,

    This?

    PET / CBM Personal Computer Guide, page 642, Original ROMs, $ FD8D Reset BASIC

    - -

    I'm totally noob, hoping "TapeCart" will work on my PET 2001-8.

    DISPLAY LESS

  • kim_jorgensen

    I'm trying to get hold of full documentation on tapecart sd. I got some information on tapecart... but tapecart SD appears to have additional commands for directory handling (80,81,82..) .

  • tapecart SD appears to have additional commands for directory handling (80,81,82..) .

    Yes, that is correct: Bitte melde dich an, um diesen Link zu sehen..
    They are documented in the code as a comment above the corresponding function, see Bitte melde dich an, um diesen Link zu sehen.

  • kim_jorgensen Thanks for the reply. I am writing some code for it in assembly. I can communicate with the tapecart sd device and read out device info and set modes.

    But i'm not quite sure how to be able to grab the directory ...

    Do you use "SD_OPEN_DIR" to initialize and open the directory the first time ? Or is there some other magic done prior to this ? I only get alot of FF FF FF's

    Einmal editiert, zuletzt von PeekyPoke (27. November 2021 um 00:28) aus folgendem Grund: forgot somehting

  • Do you use "SD_OPEN_DIR" to initialize and open the directory the first time ?

    Yes. The Bitte melde dich an, um diesen Link zu sehen. has been released so you should be able to see exactly how it was implemented. The directory readout is implemented Bitte melde dich an, um diesen Link zu sehen.

  • We are working on a few tapecart releases (yes, really :) ) and we noticed that the .TCRT support on the TapeCart SD is lacking two very important features:

    - No WRITE support. This is a huge thing, especially when people think they will get 100% compatibility. Write functionality just gets ignored on the SD variant.

    - If you are using a .TCRT image on the SD device and you reset the Tapecart using the Motor ON functionality the SD device actually fully resets, it should reset but with the .TCRT image still mounted. So basically any tapecart that is using this functionality won't work on the SD device.

  • Cool! Jetzt fehlt nur noch ein Release für MagicDesk, dann kann ich mir auch endlich ein Modul davon bauen. (Auf meinem Easyflash habbe ich es schon drauf, ist aber etwas Platzverschwendung nur für das eine Spiel und ja, ich weiss, dass es das noch als Compilation mit Ghost'n Goblins und Bruce Lee II gibt)

  • - No WRITE support. This is a huge thing, especially when people think they will get 100% compatibility. Write functionality just gets ignored on the SD variant.

    I'm not sure who thinks that they will get 100% compatibility when it was stated in the readme that there was no write support :)
    Anyway, there is a Bitte melde dich an, um diesen Link zu sehen. with write support available now

  • Super nice of you Kim!

    This will allow us to save scores and game saves in future tapecart-sd releases.

    :thumbsup: