Besoin d'informations Commodore

[minimorphee]

Salut les petits loups, 
vous avez pu le voir j'ai craqué (faut surtout pas me demander pourquoi) sur un C64 Mini.
Je me suis dit cool je vais DL des jeux et tester tout a vaec grande hate !

MAIS, j'ai DL, j'ai pleins de gigas, mais j'y comprends RIEN ! :'(
Dans mon archive j'ai des trucs nommés "collection", "compilations", "Coverdisks", "Cractos", "Games", "GEOS", etc etc...
Au début j'ai voulu me concentrer sur le dossier game, vu que je ne comprenais rien et là j'ai encore rien compris !!!

Dans le dossier GAME j'ai des trucs différents genre "C64", "CRT", "D64", "D81", G41", "G64", "LNX", "P00", "PRG", "T64", "TAP", "Z64" ! Tout ça.....
J'ai cherché sur le net, et même si j'ai pu lire à quoi cela renvoyé, j'ai du mal à comprendre et j'ai besoin d'informations, sur comment était les jeux, sous quels formats, pourquoi j'ai autant d'extension différentes, etc etc !

Si une âme charitable qui s'y connait passe par là, merci de m'aider à mieux comprendre la bête qui est totalement inconnue pour moi !

Mini

[io]

Source : http://petlibrary.tripod.com/formats.htm

the ICL index page

This page and the pages it refers to can be found in the C64 download folder ( formats.zip ) . It is taken directly without any modifications from the 64copy package by Peter Schepers which can be found in the PC tools section of the fairlight site , in the PC section .
Fellow Mac users have a thinner time of it :-<


*** Introduction to the various Emulator Formats


Compiled by:    Peter Schepers
     Started:   August 24, 1996
Last updated:   October 9, 1998


---------------------------------------------------------------------------


  There are always questions asked regarding the various formats which  are
commonly used on either the emulators or  the  real  C64.  Most  often  the
question involves conversion... "What do I do with LNX files?" or "How do I
make these files work on the C64s emulator?". This document is  an  attempt
to explain their internal structure, what to do  with  them,  and  some  of
their respective strengths and weaknesses.

  Some of what is contained in this document has been compiled from various
sources, and I have given the appropriate attributions in the  CONCLUDE.TXT
file. Some of the information may not be accurate as it may have been taken
from other documents, and I have no first-hand experience with it.  I  will
try to make it as thorough as possible, but if there  is  something  wrong,
please alert me so I can make the appropriate changes for future releases.


  So far, this document covers the following emulator types:

  * D64 (1541 disk representation, with a description  of  RELATIVE  files,
         and some D64 variants)
  * X64 (for the X64/Vice emulator)
  * T64 (Tape images for the C64s emulator)
  * T64 .FRZ (FRoZen Files, saved emulator sessions)
  * PC64 (P/S/U/Rxx)
  * PC64 .C64 (saved emulator sessions)
  * D71 (1571 disk representation)
  * D81 (1581 disk representation)
  * G64 (GCR image of a 1541 disk)
  * F64 (not an image file, but a companion file to D64's)
  * N64 (64NET's custom files)
  * L64 (64LAN's custom files)
  * C64 (PCLINK's custom files)
  * CRT (CCS64 ROM cartridge files)
  * 64x (PC64 ROM files)
  * TAP (CCS64 TAPe files)

  ...as well as the following native C64 types,  some  of  which  are  also
  supported on the various emulators:

  * 4-file diskpacked ZipCode (or .Z64, 4 or 5 files, #!xxxxx)
  * 6-file SixPack ZipCode (or .Z64, #!!xxxx)
  * Filepacked ZipCode (or .Z64, x files, x!xxxxx)
  * LNX (LyNX)
  * ARK & SRK (ARKive & compressed ARKive)
  * LHA & LZH (header description only)
  * SFX (SelF-eXtracting LHA/LZH)
  * SDA (Self-Dissolving Archive)
  * ARC (ARChive)
  * ZIP (PKZIP)
  * CKIT (Compression KIT)
  * CPK
  * WRA (Wraptor)
  * LBR (LiBRary, C64 only, not the C128 CP/M .LBR files)
  * GEOS VLIR (Variable Length Index Record)
  * CVT (GEOS ConVerT files)
  * SPY (SPYne)
  * Binary

  Also included is a very basic look at some C64 graphic bitmap formats (in
BITMAP.TXT), and the  saved  session  layout  of  the  Macintosh-based  C64
emulator "Power64" (in POWER64.TXT). Thanks to Peter Weighill for the above
info.

  At  the  end  of  the  CONCLUDE.TXT  document  is  a   BINARY/HEX/Decimal
conversion chart, useful when you don't know  how  to  convert  the  number
bases around. It might come in handy when working  with  and  understanding
the GCR conversion that the SixPack ZipCode format uses.

  Right now there are several good utilities available to work with most of
the mentioned formats. The first is 64COPY, my own conversion program.  The
second is Star Commander, by Joe Forster/STA. Included with his program are
many smaller utilities such as Star ARK, Star LHA and Star ZIP, which  will
convert specific formats to D64 images.

                                                 Peter Schepers,
                                                 University of Waterloo.

                                          Email: schepers@ist.uwaterloo.ca


---------------------------------------------------------------------------


Most recent changes:

June 2/98 - Added new section to D64, D71, D81, PC64, LNX, T64  and  BINARY
            dealing with the good/bad aspects of the layout
          - Updated F64 topic
          - Updated GEOS topic

June 8/98 - Added CCS64 ROM cartridge file (CRT)
          - Added a "document revision" number to each TXT file. This  way,
            version history can be tracked, and you will always know if you
            have the latest revision.
          - Added description of PC64 ROM files (64x)

 Oct 9/98 - Updated SDA topic
          - Added new G64, a 1541 GCR disk image

Feb 16/99 - Added a basic TAP description

Aug 13/99 - Added PSID/Sidplay formats
          - Updated G64 format


---------------------------------------------------------------------------


*** Terms and acronyms

  Many strange terms have come along with computers in general, and I  will
not attempt to explain them all, but some of the ones in this document  may
not be entirely clear. I will attempt to make things  a  little  easier  by
explaining some of the more common ones.


   - Short form for a Carriage Return ($0D) symbol.

   - Short form for a Line Feed ($0A) symbol.

  ASCII - This is an acronym for "American Standard  Code  for  Information
          Interchange". The standard  is  a  7-bit  code  covering  control
          codes, punctuation, alphanumeric (A to Z, 0 to 9) as well as math
          and a few other symbols. Since it is a 7-bit code, it ranges from
          $00 to $7F (0-127). This leaves the top 128-255 definable by  the
          vendor. The PC world has corrupted this standard making it 8-bit.

  BAM - An acronym for "Block Availability Map". Here  is  where  the  disk
        operating system keeps track of  what  sectors  are  allocated  (or
        available) for each track.

  BLOCK - This refers to sectors which  on  a  logical  level  are  grouped
          together. On a 1541 disk, it could be a series of sectors  linked
          together in a file, or a partition on a  1581  disk.  In  the  PC
          world it represents a "cluster"  of  sectors.  Generally  if  I'm
          referring to a grouping of sectors thats *not* 256  bytes  large,
          then I talk in blocks.

  BYTE - A group of 8 bits, the contents of 1 memory location.

  CHAIN - A series of sectors linked  together.  One  sector  will  have  a
          pointer to another, and that sector will point to another,  until
          the chain has no more forward pointers. A file stored on  a  1541
          disk would be considered a chain of sectors, but it  also  has  a
          directory entry explaining what the chain is for.

  FILETYPE - In the Commodore world, this would be the kind of file, be  it
             SEQ, REL, PRG, USR, GEOS etc. In the  DOS  world,  this  would
             possibly be the file extension, be it EXE, TXT, DOC. It  tells
             the user what file it is, making usage easier.

  GCR - An acronym for "Group Code Recording". This is the encoding  method
        Commodore uses to physically store the  information  on  the  disks
        (i.e. 1541). It encodes an 8 bit sequence into a 10 bit sequence so
        that long repeated sequences of 1's or 0's are avoided. These  must
        be avoided so that the timing of reading/writing to the disk  won't
        become "out of sync". As a user, you would not normally see the GCR
        information since the drive does all the conversion to  normal  HEX
        data before it gives it to you.

  HIGH/LOW - The bytes here are stored backwards compared to  the  LOW/HIGH
             method. See LOW/HIGH for more information.

  LINK - This is the track/sector values, stored in the first two bytes  of
         a sector, which point to (or "link" to) the t/s  location  of  the
         next sector. A  series  of  these  links  comprise  a  "chain"  of
         sectors.

  LOW/HIGH - This is how values are stored when they  exceed  one  byte.  A
             good example of this is the sector count of  a  D64  file.  To
             calculate the actual value, take the second value, multiply it
             by 256 and add the low  value.  You  will  now  get  the  real
             decimal value. i.e. (HIGH*256)+LOW=result.

             If you look at is as a HEX value, swap the  bytes  around  and
             put them together for the 16-bit HEX value. i.e. $FE $03 would
             be $03FE as a 16-bit HEX value.

  LSB/MSB - See LOW/HIGH.

  LSU - This is my own acronym meaning "last  sector  useage".  It  is  the
        value stored in byte position $01 (the "sector" value  of  the  t/s
        link) of the last sector of a file. This value is the offset  into
        the sector where the last byte is stored. It  also  represents  the
        byte count + 1, since a value of 255 would actually mean  only  254
        bytes of file data exists (full sector less the  2  bytes  for  t/s
        chain). Without reasonable knowledge of the disk layout, this  byte
        can be confusing, and hard to explain.

  NYBBLE - A grouping of 4 bits (half a byte), either the first or  last  4
           bits of an 8-bit binary number,  or  one  half  of  a  two-digit
           hexadecimal number.

           Typically, a byte will be broken down into two parts, the top  4
           bits and the bottom 4 bits. These are referred to as  the  upper
           and lower  nybble  respectively,  and  are  represented  by  two
           hexadecimal digits in base 16.

  PETASCII - (or PETSCII) This is Commodore's version  of  ASCII  (the  PET
             part of the name comes from the  first  computer  to  use  the
             code, the PET or Personal Electronic Transactor).

             Most of the codes from 0-127 are the same as ASCII, but  there
             are differences, especially  noticible  when  converting  text
             from a C64  to  a  DOS  machine.  Where  ASCII  has  uppercase
             characters, PETASCII has lower  case  ones,  and  vice  versa.
             Also, the top 128 characters (128 to 255) are quite  different
             from the PC "standard".

  RLE - An acronym for "Run Length Encoding". This is a simple  compression
        method, employed by most compression programs,  and  also  used  by
        some archive formats  (ZipCode,  CPK).  It  encodes  sequences  (or
        "runs", hence the name "RUN length...") of the same byte  (i.e.  00
        00 00 00 00  00)  into  a  smaller  string  using  a  shorter  code
        sequence, making the resultant file smaller than the original. This
        is the simplest form of file compression.

  SECTOR - It is best described as the method that the drive uses to  store
           the smallest group of bytes physically on the disk. On the  1541
           this refers to a group of 256 bytes stored together in a  single
           sector. On a PC disk, this is typically 512 bytes.

  SIGNATURE - A group of bytes, usually near or at the front of  the  file,
              which are used to identify the type of file. i.e. a PC64 file
              will always have the signature string "C64file" contained  at
              the beginning of the file.

  TAR - An acronym for "Tape ARchiver", a UNIX application, and  method  of
        backing up information.

_INTRO._ repeat of text above without this table !

_64LAN_

_64NET_

_ARC_

_ARK-SRK_

_BINARY_

_BITMAP_

_C64S_FRZ_

_CCS_CART_

_CKIT_

_CPK_

_CVT_

_D64_

_D71_

_D81_

_F64_

_G64_

_GEOS_

_LBR_

_LHA_

_LNX_

_PC64_

_PC64_FRZ_

_PC64_ROM_

_PCLINK_

_POWER64_

_SDA_

_SFX_

_SIDPLAY_

_SPYNE_

_T64_

_TAP_

_WRA_

_X64_

_ZIP_

_ZIP_DISK_

_ZIP_FILE_

_ZIP_SIX_ have a bunch of 4 or 6 files with ! in the names ?

_CONCLUDE_

[minimorphee]

Donc si je comprends bien, certains formats correspondent à des anciens pc (genre le pic je ne sais plus quoi) et d'autre format sont des jeux sur différent support (cassette, disquette) ?
J'ai vraiment du mal à tout cerner ^^'

J'ai tester de mettre un je ude chaque dans mon C64 Mini, et certains se lance, d'autre pas du tout =x

Mini

[DataPro]

Pour simplifier au maximum, D64 se sont des images binaires de disquettes et T64 des images binaires de cassettes.
Déjà, avec çà, tu auras accès à plus de jeux que de temps pour les essayer.

En général dans les émulateurs, tu prends une image de disque .D64, tu la place dans un lecteur virtuel puis après çà fonctionne comme sur la vraie machine.
L'écran du DOS s'affiche et attend tes ordres (c'est comme le CMD de Windows, une ligne de commande.)

Si tu tapes :
LOAD"$",8
tu peux charger le catalogue de la disquette (liste des fichiers qui sont dessus).

Et là, justement, les programmes sont les fichiers qui se terminent par l'extension .PRG (comme sur Atari ST)
Si tu vois AIRWOLF.PRG dans la liste
tu tapes RUN "AIRWOLF.PRG",8 et le programme est lancé.

Un .PRG c'est comme un .EXE sur PC

Il existe des programmes de shell pour parcourir plus rapidement les images-disks; je ne sais pas s'il y en a un intégré à ton émulateur.
J'utilise une carte SD sur un vrai Commodore 64

[youtube]DVEQua5bADs[/youtube]

[frodon69]

35€ au lieu de 80 chez Auchan, je réfléchis...
https://www.auchan.fr/jeux-video/consol ... 1710131553

[Nico]

Oui, à 35 € j'ai craqué, je l'ai reçu hier mais je ne l'ai pas encore ouvert

[minimorphee]

Lancé vous les gars, par contre prévoyais tout ca :
Hub usb
Clef usb pour les jeux
Une autre manette car celle fournie se casse hyper vite
Un clavier usb, car passer par le clavier virtuel c'est hyper naze, voir injouable pour certains jeux

Premier truc a faire après achat, mettre le frimware a jour piur profiter de la prise en charge native des jeux sur usb, et de pads next gen aussi.

Amusez vous bien, surtout avec les jeux quibsortent en homebrow en ce moment sur c64 !

Mini

[Nico]

Merci, c'est intéressant tout ça !