8050er LOS-96 Diskette aus Image mit Kryoflux erstellen?

  • Moinsen!


    Habe hier noch einen 8032SK mit einer Zusatzplatine mit 64K RAM und ein paar anderen kleinen ICs drauf. Ich vermute, dass es eine 64K-Erweiterungsplatine ist, die den 8032 zu einem 8096 aufruestet. Die Karte steckt im Prozessor-Sockel, der Prozessor selbst wiederum auf der Karte. Kein anderer Prozessor, als der 6502 drauf (also keine Z80 oder Graphics Karte (leider - hehe).


    doof ➜ Nun habe ich aber keine LOS-96 Diskette, mit der ich das testen könnte. ⬅ doof :fp:


    "HA!" dachte ich "Wozu haste dat Kryoflux-Jedöns?" ^^ Flugs setzte ich mich also an mein Fenster zum Internet und fing an, nach LOS-96 Images zu suchen, als mir einfiel, dass die Commodore-8050er Laufwerke mit 100 tpi arbeiten 8| .


    Hat man da mit Kryoflux und 'nem normalen 96tpi-Laufwerk überhaupt eine Chance? :grübel: Hat das schon wer probiert?


    Zusatzfrage für gelangweilte CBM-Gurus:


    Kann man das LOS-96 auch irgendwie in ein ROM brennen und von dort aus aktivieren? Zwei ROM-Sockel sind in der Maschine noch frei.


    -- Klaus


    PS: Antwort hat Zeit, ich geh' jetzt erstmal in die Altstadt - so schön warm wie heute dürfte es dieses Jahr nicht mehr werden... Prost!

    [ ... to boldly code where no byte has gone before ... ]

  • Zum Thema Kryoflux und CBM-8050-Format hat Toast_r einige Anstrengungen unternommen. TL;DR: mit 96 TPI-Laufwerken niemals, mit 100-TPI-Laufwerken vielleicht eines Tages.


    Ein LOS-96-Disk-Image kann ich Dir gerne zusenden. Falls Du neben dem Kryflux auch ein ZoomFloppy besitzt, könntest Du es damit auf Diskette schreiben.


    Für die Erweiterung-ROMs ist das aber zu groß.

  • Zusatzplatine mit 64K RAM und ein paar anderen kleinen ICs drauf.

    bite ein bild zeigen.

    Kann man das LOS-96 auch irgendwie in ein ROM brennen und von dort aus aktivieren? Zwei ROM-Sockel sind in der Maschine noch frei.

    die beiden rom-sockel (2x4KB) reichen nicht aus.


    ich hatte einen universal userport eprom adapter für pet, cbm, c64 usw.
    da wurde die eprom adresse hochgezählt mit 74ls393 und die eprom daten wurden direkt eingelesen.


    so habe ich es auch bei dem prom / eprom brenner gemacht für alle commodore geräte mit userport.


    so konnte man ohne floppy, sehr schnell, programme einlesen. dazu gehörte ein geändertes editor-eprom $Exxx.


    auch eine adapter version mit einem zweiten userport, uhr und rams / eproms, der in den 6502 sockel kam, hatte ich.
    ein bild von der platine mit einem userport und einer uhr habe ich im forum64 gefunden:
    https://www.forum64.de/index.p…t-proxa-ultra-electronic/


    gruß
    helmut

    Einmal editiert, zuletzt von axorp ()

  • Schaue mal, was VICE alles kann ... da kann man sich im Prinzip alles ins gewünschte BLANK-Image ziehen ... TPI hin oder her ... nur mal als Idee:


    2.10 The disk drive emulation


    All the emulators support up to 4 external disk drives as devices 8, 9, 10 and 11. Each of these devices can emulate virtual Commodore 1541, 1541-II, 1571, 1581, 2031, 2040, 3040, 4040, 1001, 8050 and 8250 drives in one of four ways:
    ◾ using disk images, i.e., files that contain a dump of all the blocks contained in a real floppy disk (if you want more information about what a disk image is, consult the comp.emulators.cbm FAQ);
    ◾ accessing file system directories, thus giving you the use of files without having to copy them to disk images; this also allows you to read and write files in the P00 format (again, consult the comp.emulators.cbm FAQ for more info).
    ◾ accessing a real device connected to the host machine. As of VICE 1.11 it is possible to connect real drives like Commodore 1541 to the printer port of the host using the XA1541 or XM1541 cable. Currently this only works on Linux or Windows using the OpenCBM library. You can get it from http://www.lb.shuttle.de/puffin/cbm4linux (cbm4linux, Linux version) or from http://cbm4win.sf.net (cbm4win, Windows version).
    ◾ directly using the disk drive of the host. The 3.5" disk drive of the host can be used to read or write Commodore 1581 formatted disks. Currently this raw drive access feature is only available for Linux hosts.


    When using disk images there are two available types of drive emulation. One of them the virtual drive emulation. It does not really emulate the serial line, but patches the kernal ROM (with the so-called kernal traps) so that serial line operations can be emulated via C language routines. This emulation is very fast, but only allows use of standard DOS functions (and not even all of them). For real device or raw drive access it is required to enable this type of emulation.


    The IEEE488 drives (2031, 2040, 3040, 4040, 1001, 8050 and 8250) do not use kernal traps. Instead the IEEE488 interface lines are monitored and the data is passed to the drive emulation. To use them on the C64, you need to enable the IEEE488 interface emulation. Only if the IEEE488 emulation is enabled, those drives can be selected.


    The other alternative is a true drive emulation. The Commodore disk drives are provided with their own CPU (a 6502 as the VIC20 and the PETs) and their own RAM and ROM. So, in order to more closely emulate its features, a complete emulation of this hardware must be provided and that is what the hardware level emulation does. When the hardware level emulation is used, the kernal routines remain unpatched and the serial line is fully emulated. The problem with this emulation is that it needs a lot of processing power, mainly because the emulator has to emulate two CPUs instead of one.


    The PETs do not use a serial IEC bus to communicate with the floppy drive but instead use the parallel IEEE488 bus. This does byte by byte transfers, as opposed to the bit by bit transfers of the C64 and VIC20, so making it feasible to emulate the parallel line completely while emulating the drive at DOS level only. The IEEE488 line interpreter maps the drives 8-11 (as described above) to the IEEE488 disk units, and no kernal traps are needed. The same emulation of the Commodore IEEE488 bus interface is available for the C64 and the VIC20. With IEEE488 drives you can have true 2031 emulation at unit #8, and still have filesystem access at units #10 or #11, because monitoring the IEEE488 lines does not interfere with the true drive emulation.


    The IEEE488 disk drives 2040, 3040, 4040, 8050 and 8250 are Dual Drive Floppy Disks. This means that these drives handle two disks. To accomplish the emulation, only two disks can be emulated, namely units #8 and #10. The attached image, track display and LED display of unit #9 and #11 are used for the second drive of the dual disk drives. On unix the unit number display (8 or 9, 10 or 11) in the emulation window changes to the drive number display (0 or 1).


    The Commodore 2040, 3040, 4040, 1001, 8050 and 8250 disk drives are so-called "old-style" disk drives. Their architecture includes not one, but two processors of the 6502 type, namely a 6502 for the file handling and communication with the PET (IP), and a 6504 (which is a 6502 with reduced address space) for the drive handling (FDC). Both processors communicate over a shared memory area. The IP writes commands to read/write blocks to this area and the FDC executes them. To make the emulation feasible, the FDC processor is not emulated cycle-exactly as a 6504, but simply by checking the commands and executing them on the host. This provides a fast FDC emulation, but disallows the sending the FDC processor commands to execute code. Applications where this is necessary are believed to be rather seldom. Only the format command uses this feature, but this is checked for.


    The dual disk drive 2040 emulates one of the very first CBM disk drives. This drive has DOS version 1. DOS1 uses an own disk type, that is closely related to the 1541 disk image. Only on tracks 18-24 DOS1 disks have a sector more than 1541 disks. DOS1 disk images have the extension .d67.


    The dual disk drives 3040 and 4040 use the same logical disk format as the VC1541 and the 2031. In fact, the 4040 was the first disk with DOS version 2. The 3040 emulated here originally was the same as 2040, only for the european 30xx PET series. As many of the original DOS1 disk drives were upgraded (a simple ROM upgrade!) to DOS2, I use the 3040 number for a DOS 2.0 disk drive, and 4040 for a revised DOS 2 disk drive. It is, however, not yet clear whether the disks here are write compatible to the 1541, as rumors exist that the write gap between sectors is different. But read compatible they are. As VICE emulates the FDC processor in C and not as 6504 emulation, this does not matter in VICE.


    The drives 1001, 8050 and 8250 do actually have the very same DOS ROM. Only the code in the FDC is different, which is taken care of by VICE. So for all three of those disk drives, only dos1001 is needed. The DOS version used is 2.7.


    2.11 Supported file formats


    VICE supports the most popular Commodore file formats:
    ◾ X64 (preferred) or D64 disk image files; Used by the 1541, 2031, 3040, 4040 drives.
    ◾ G64 GCR-encoded 1541 disk image files
    ◾ P64 NRZI flux pulse disk image files
    ◾ D67 CBM2040 (DOS1) disk image format
    ◾ D71 VC1571 disk image format
    ◾ D81 VC1581 disk image format
    ◾ D80 CBM8050 disk image format
    ◾ D82 CBM8250/1001 disk image format
    ◾ D1M FD2000/FD4000 DD disk image format
    ◾ D2M FD2000/FD4000 HD disk image format
    ◾ D4M FD4000 ED disk image format
    ◾ T64 tape image files (read-only)
    ◾ P00 program files
    ◾ CRT C64 cartridge image files


    An utility (c1541, see section 13 c1541) is provided to allow transfers and conversions between these formats.


    Notice that the use of the X64 file format is depreciated now.


    You can convert an X64 file back into a D64 file with the UNIX dd command:
    dd bs=64 skip=1 if=IMAGE.X64 of=IMAGE.D64



    See section 16 The emulator file formats. for a technical description of the supported file formats.

    • Offizieller Beitrag

    p-system?
    kenne ich nicht. von wem ist es?



    Das ist ein Betriebssystem, welches Programme mit portablen Code unterstützt (der sog. p-code). Es gibt für jede CPU einen dedizierten p-code interpreter (6502, Z80, VAX, 68000, 6800, TMS9900, LSI-11, 8080, 8086....). Ein nach p-code auf dem Atari ST kompiliertes Programm läuft auch auf dem CBM 8096....Gibt/gab verschiedene Programmiersprachen, BASIC, Pascal, Modula-2 und natürlich Pascal.

  • Witzbold!

    wiso, keine kamera oder handy vorhanden?


    sieht die platine so aus wie im oberen forum64 link?


    gruß
    helmut

  • Schaue mal, was VICE alles kann ... da kann man sich im Prinzip alles ins gewünschte BLANK-Image ziehen ... TPI hin oder her ... nur mal als Idee:
    (... 2148 lines deleted)
    See section 16 The emulator file formats. for a technical description of the supported file formats.

    Hallo, E.D. - ich fragte nach konkreten Erfahrungsberichten und nicht nach theorethischen Moeglichkeiten,,, Vom Emulatoren hab' ich auch nie geredet!


    -- Klaus

    [ ... to boldly code where no byte has gone before ... ]

  • wiso, keine kamera oder handy vorhanden?


    sieht die platine so aus wie im oberen forum64 link?


    gruß
    helmut

    Hmm, gehen Bilder-Uploads wieder?

    [ ... to boldly code where no byte has gone before ... ]

  • Zum Thema Kryoflux und CBM-8050-Format hat Toast_r einige Anstrengungen unternommen. TL;DR: mit 96 TPI-Laufwerken niemals, mit 100-TPI-Laufwerken vielleicht eines Tages.


    Ein LOS-96-Disk-Image kann ich Dir gerne zusenden. Falls Du neben dem Kryflux auch ein ZoomFloppy besitzt, könntest Du es damit auf Diskette schreiben.


    Für die Erweiterung-ROMs ist das aber zu groß.

    Hmm - dachte mir schon, dass das mit den 96-tpi-Laufwerken nicht geht - wollte das aber nochmal bestaetigt haben. Dann muss ich mir mal bei nem Retro-Treff eine Kopie geben lassen.


    ZoomFloppy habe ich natuerlich nicht...


    Aber Danke für die Response!


    -- Klaus

    [ ... to boldly code where no byte has gone before ... ]

  • ich hatte einen universal userport eprom adapter für pet, cbm, c64 usw.
    da wurde die eprom adresse hochgezählt mit 74ls393 und die eprom daten wurden direkt eingelesen.

    Hmm klingt interessant - vielleicht gucke ich irgendwann auch mal in diese Richtung weiter. Merci fuer den Hinweis!


    -- Klaus

    [ ... to boldly code where no byte has gone before ... ]