
 VICE version 0.11 PL 0						31 July 1996







				 T h e

		 _______________
		|      ||      ||
		|      ||      ||____________________________
		|      ||      ||    ||         ||          ||
		|      ||      ||    ||    |    ||    ______||
		|      ||      ||    ||    |----||          ||
		|      ||      ||    ||    |    ||    ------||
		|              ||____||_________||__________||
		 \            // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
		  \          //
		   \________//


	    P r o g r a m m e r s '   R e v e n g e   M a n u a l







		   Special features in CBM 8-bit emulation
				    and
			  Emulator File Conversions














		    Copyright (C) 1993-1996, Project X64
			     All right reserved.




 -----------------------------------------------------------------------------
 No part of this  document may  be read using  any kind of  Microsoft product.
 Microsoft Network is prohibited from redistributing this work in any form, in
 whole  or  in part, without  a license.  License to distribute  this document
 is available  to Microsoft  for GBP 500. Use in  any of  aforementioned  ways
 without  permission constitutes an agreement to these terms and may result in
 liability. Report violations to the VICE authors and postmastr@microsoft.com.
 -----------------------------------------------------------------------------















	Legal Notice

  You may distribute verbatim copies of this document SEPARATELY of the
  VICE emulator under the conditions that it is transmitted to all parties
  (1) in its entirety, (2) unchanged and (3) free of charge.



  The program names for VICE are built along the Unix/X11 convention and any
  resemblance with other products, e.g. "A64" or "x1541", is unintended and
  purely coincidental.

  Names reserved for use in this project are the following:

        c1541, xc1541, x64, x128, xvic, xpet, and petcat, Project X64,
	VICE, Versatile Commodore Emulator, and Virtual Commodore
	Environment.




	Trademark Acknowledgements

  Commodore C64, C128:	ESCOM
			(originally Commodore Business Machines, Inc.)

  OC-118:		Oceanic Electronic, Ltd.

  Star LC-10C:		Star Micronics Co., Ltd.



























 Introduction to the VICE Emulator/Simulator system on the hardware and
 compatibility point of view, and available third-party tools.

 All details are subject to change without any prior notice.



	INDEX

	1. DETAILS OF CPU EMULATION
	1.1  6510 Features in Emulation
	1.2  6502 instruction coding
	1.3  The MOS 65xx CPU Programming Model
	1.4  CPU Peripheral Port
	1.5  6502 Undocumented Mnemonic Dialects
	1.6  6502 and later processors Addressing Modes availability
	1.7  Interrupts
	1.8  Interrupt Sources


	2. MEMORY
	2.1  System ROMs
	2.2  I/O Decoding
	2.3  C64 vs. 128 incompatibility
	2.4  REU -- Ram Expansion Unit
	2.5  Internal Memory Expansions
	2.6  Emulator Detection

	2.7  The C128 MMU

	3. C128 CP/M OPERATING MODE
	3.1  Zilog Z80 CPU
	3.2  CPU Comparison
	3.3  I/O Accessing
	3.4  Processor Switching
	3.5  CP/M Plus
	3.6  CP/M Memory Layout


	4. SCREEN EMULATION AND VIC

	  VDC -- the C128 80 col Display Controller
	     VDC 8563  Register Definitions
	     VDC Attribute Memory

	  C128 VDC RAM (80 column display)


	5. Sound, SID


	6. I/O Ports
	6.1  The CIAs
	6.2  Tape Unit
	6.2.1 Tape File Header Format
	6.2.2 Tape Turbo
	6.2.3 Tape with Disk Turbo


	7. KEYBOARD
	  C64/C128 Keyboard Layout
	  VIC-20 Keyboard Matrix
	  C64 Keyboard Matrix
	  C128 Keyboard Extension
	  Commodore 128 keycodes
	  The keyboard emulation on X64


	8. SERIAL BUS PERIPHERALS
	8.1 Serial Bus
	  X64 Traps
	    Kernel idle traps
	    Serial module traps.  
	    Serial loop-back traps

	8.2  Disk Drive
	8.2.1 The 1541
	8.2.2 The 1571
	8.2.3 Other drives
	8.2.4 Filesystem (FS) Drive

	8.3 PRINTER
	  Locale
	  International Charsets
	  International Character Codes
	8.3.x Graphics


	9. FILE COMPATIBILITY
	9.1  Commodore 64 ROM Images
	    X64 ROM Image Set
	    C64S Romcode
	    Mac64 ROM Resource File
	    A64 romcode

	9.2  Commodore 128 ROM Images

	9.3  Commodore Plus/4 ROM Images

	9.4  Commodore VIC-20 ROM Images

	9.5  Commodore PET ROM Images

	9.6  *.C64 Image File

	9.7  X64 Ram File
	    X64 Snapshot [draft]

	9.8  Disk Image Files
	    X64 Disk File
	    *.D64 disk File
	    GEOS File Format

	9.9  Tape Image Files
	    *.T64 tape image

	9.10 Program File
	    CBM Files
	    *.P00

	9.11 SID Music Files
	    Playsid

	9.12 CBM Archive formats


	10. PROGRAMMING / CONVERTING PROGRAMS
	10.1  Program file format conversions
	10.2  Listing Basic Programs
	10.3  Porting BASIC Programs
	10.4  Tricks on BASIC RAM

	11. OTHER PROGRAMMING LANGUAGES
	11.1  High-Level Languages
	11.1.1 FORTH
	11.1.2 C
	11.2  Machine Language Programs
	11.2.1 Machine Language Monitors
	11.2.2 Assemblers
	11.2.3 Reassemblers
	11.2.4 Cross Assemblers and Disassemblers / Reassemblers


	12. FILE CONVERSIONS
	12.1  Listing
	12.2  Text Files

	12.3  Converting CBM Archives
	12.3.1  Commodore 64/128 Compression Software
	12.3.2  Lynx Archives
	12.3.3  Convert Commodore ZIPCODE format to .D64
	12.3.4  Dissolving big ZipCode files
	12.3.5  .D64 -> Zipcode
	12.3.6  * LHA
	12.3.7  * GNU ZIP
	12.3.8  Compactors
	12.3.9  Universal dearchivers

	12.4  Emulator Archives
	12.4.1 Disks
	12.4.2 Tapes

	12.5  Images
	12.5.1 General
	12.5.2 GIF
	12.5.2.x Geos GIF viewer
	12.5.2.x C128 GIF viewer
	12.5.3 VBM
	12.5.4 IFLI
	12.5.5 SRF - Self Running FLI
	12.6  SID tunes


	13. TRANSFER
	13.1  CD-ROM
	13.2  CBM
	13.3  Amiga
	13.4  PC
	13.4.1 What you'll need
	13.4.2 PC Transfer Cable
	13.4.3 PC Transfer Programs
	13.5  CBM Networking

	14. FURTHER READING
	14.1  VICE Documents
	14.2  Other Documents
	14.3  FAQs
	14.4  FTP sites
	14.5  Internet Resources
	14.6  Commodore Manuals


	15. ACKNOWLEDGEMENTS



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


  1. DETAILS OF EMULATION


  1.1  6510 Features in Emulation

	JMP($indirect) doesn't have the wrap-aroud bug
	RMW instructions don't write data back at incorrect address first.
	Undocumented commands only perform the most common behaviour.
	Clock cycle count is not incremented when page boundary crossing or
	 conditional branch takes place.
	Any information on incompatibility is welcome.


  1.2  6502 instruction coding

 Unlike an average intel, the 6502 (at least the MOS/Commodore designs)
 doesn't have microcode  (1), according to an authoritive source who answered
 a similar question in comp.sys.cbm several years ago.

 Instead, a state device is utilised to enable each piece of operation at
 the correct time.

		+----------+-------+----------+-----+-----+-----+
  Current State	|  Opcode  | Cycle |  Flags   | Res | Irq | Nmi |
		+----------+-------+----------+-----+-----+-----+
		\_______ _________/ \___________ _______________/
			|			|
			V			V
		   ALU Enable	      Next State Branch Control
		   Register Enable
		   Bus Enable


 Notice that Reset only is a special interrupt -- or in Motorola (2) techspeak,
 an exception -- like the other interrupts.
 Thus, upon Reset, the CPU does not lose the contents of its registers and it
 even stores the most important of them onto the stack -- you just don't know
 where.
 Even though the Reset doesn't directly force the logic to any specific state,
 it can recover the CPU from any imagineable state put by opcodes even without
 any addressing mode (codes 02, 12, ...) as long as no electronic deadlocks are
 involved.

 Also, there was a rumour about ten years ago, probably originated from some
 magazine, claiming that the 6502 is a RISC (Reduced Instruction Set Computer)
 processor. It seems the remark was merely a joke.
 As a matter of fact, the 6502 is not even near RISC, despite the fact the
 instruction set is very limited. The 6502 only fulfills two of the 7 major
 demands. One of the missing features is pipelining, BTW.


 But would there be any advantage of emulating the way the c64's processor
 (6510) calculates each instruction ?
 The main problems with the emulators are not problems with how the machine
 language instructions (e.g INX CPX BNE  etc..) are calculated or executed.
 The majority of the problems arise from timing issues i.e sprite corruption,
 fast loaders and character set corruption in the different screen sections.
 The majority of these problems don't arise from cpu crash or problems with
 opcode emulation rather timing inconsistencies like inaccurate raster line
 emulation which results in the missing sprite parts, screen corruption, etc
 listed above.
 Some of these problems can't be helped because exactly perfect emulation 
 would waste processor time requiring the base machine to run these 
 emulators up to pentium machines.

 Notes:
 (1) Microcode is the code _inside_ the processor that executes the
     machinecode. The microcode is responsable for getting data from
     memory, putting it into registers, updating the PC, and doing an
     occasional branch.

 (2) The 6502 is originally based on the Motorola MC6800 processor.


  1.3  The MOS 65xx CPU Programming Model


		Bits		Register
	15     8 7      0

		 xxxxxxxx	AC	Accumulator

		 xxxxxxxx	XR	Inder Register X

		 xxxxxxxx	YR	Inder Register Y

	xxxxxxxx xxxxxxxx	PC	Program Counter

	       1 xxxxxxxx	SP	Stack Pointer

		 NV1BDIZC	PS/SR	Processor Status Register


	    N = Negative		    D = Decimal Mode
	    V = Overflow		    I = IRQ Disable
	    1 = Unused			    Z = Zero
	    B = Software Interrupt (BRK)    C = Carry


		Comparison Result

		Z C	Result

		0 0	A < B
		1 0	A = B
		0 1	A > B


			Suitable Branches
	+--------+-----+--------------------+--------------------+
	|  Test  | Z C |  True		    |  False		 |
	+--------+-----+--------------------+--------------------+
	| A  < B | 0 0 |  BEQ over: BCC a   |  BEQ a: BCS a	 |
	| A <= B | x 0 |  BCC a		    |  BCS a		 |
	| A  = B | 1 0 |  BEQ a		    |  BNE a		 |
	| A >= B | ? ? |  BEQ a: BCS a      |  BEQ over: BCC a   |
	| A  > B | 0 1 |  BCS a		    |  BCC a		 |
	+--------+--------------------------+--------------------+



 1.4  CPU Peripheral Port


	8502 I/O Registers

	C128 mode:

0000	x	0	1	0	1	1	1	1
0001	x	Caps	Motor	Sense	Write	HiRes	LoRes	Color


	C64 mode:

0000	0		7-0	MOS 8502 Data Direction Register (xx101111)
					Bit= 1: Output, Bit = 0: Input,
					 x = Don't Care	

0001	1			MOS 8502 Micro-Processor On-Chip I/O Port
			0	/LORAM Signal (0=Switch	BASIC ROM Out)
			1	/HIRAM Signal (0=Switch Kernal ROM Out)
			2	/CHAREN Signal (O=Swith Char. ROM In)
			3	Cassette Data Output Line
			4	Cassette Switch Sense: 1 = Switch Closed
			5	Cassette Motor Control:	0 = ON, 1 = OFF
			6-7	Undefined


	VIC-20 and PET

   There is no Peripheral Port on the 6502.



  1.5  6502 Undocumented Mnemonic Dialects

 Separate C64 user groups use different mnemonics for the undocumented
 opcodes. The ones selected for VICE are from the most widely known set,
 except few deviations for clarity. Here is a conversion table for the
 non-standard mnemonics:


Opcode  VICE   C=Hacking,  C64         J West     Expose    Pure-byte
               C-Lehti     Konekieli
0b,2b   ANC        *          -          ALC        ANA        ANF
8b      ANE        *          -          XAN        XMA         *
6b      ARR        *          -          RAR        RAM        ANL
4b      ASR        *          -          SAR        RBM        ANL
        DCP        *         DCMP         *          *          *
        ISB        *         ISBC        ISC         *         ISC
x2      JAM        *          -          HLT        CRS        TLT
bb      LAS       LAE         -          SAM         *         LAE
        LAX        *         LDAX        LXA         *          *
ab      LXA        *          -          LAX        AMA         *
        NOOP      NOP         -           *         SKP      NOD,NOS,NOT
        RLA        *         RLAN         *         LAN        RLN
        RRA        *         RRAD         *         RAD         *
        SAX        *         STAX         *         AAX         *
        SBX        *          -           *         AXM         *
93,9f   SHA        *        - ,????      STR        TEA         *
9b      SHS        *          -          SRS        AXS         *
9e      SHX        *         ????        XAM        TEX         *
9c      SHY        *          -          YAM        TEY         *
        SLO        *         SLOR         *         LOR         *
        SRE        *         SREO        LSE        REO         *
eb      USBC      SBC         -          SBC        SBC        USB


     Legend:
	*   mnemonic is identical to the one on VICE.
	-   mnemonic not listed
	?   unknown

 The 6510 and the 6502 have exactly the same op-codes (except that the
 NMOS 6510 didn't blank out unimplemented op-codes, resulting in some
 'illegal opcode' or whatever you want to call them: the CMOS versions either
 have these as null operations or as extensions of the 6502 instruction set).



  1.6  6502 and later processors Addressing Modes availability


  Addressing Mode	Code	6502	R65C02	GSG65CE02 G65SC802
				8502	R65C102		  G65SC816
					R65C112

Implied				 x	 x	  x	   x
Accumulator		A	 x	 x	  x	   x
Immediate		#	 x	 x	  x	   x
Immediate Word		#	 -	 -	  X	   -
Zeropage		zp	 x	 x	  x	   - 1)
Zeropage,X		zp,x	 x	 x	  x	   - 1)
Zeropage,Y		zp,y	 x	 x	  x	   - 1)
Absolute		abs	 x	 x	  x	   x
Absolute,X		abs,x	 x	 x	  x	   x
Absolute,Y		abs,y	 x	 x	  x	   x
Indirect		(ind)	 -	 X	  X	   - 2)
Indexed Indirect	(ind,x)	 x	 x	  x	   - 3)
Indirect Indexed,Y	(ind),y	 x	 x	  x	   - 3)
Indirect Indexed,Z	(ind),z	 -	 -	  X	   -
Abs Indirect		(abs)	 x	 x	  x	   x
Abs Indexed Indirect	(abs,x)	 -	 X	  X	   X
Relative		rel	 x	 x	  x	   x
Relative Long		rl	 -	 -	  X	   X
Zeropage Test Relative	zp, rel	 -	 -	  X	   -
Stack Pointer Relat (disp,sp),y	 -	 -	  X	   -

Absolute Long		al	 -	 -	  -	   X
Absolute Long,X		al,x	 -	 -	  -	   X
Direct			d	 -	 -	  -	   X 1)
Direct Indexed With X	d,x	 -	 -	  -	   X 1)
Direct Indexed With Y	d,y	 -	 -	  -	   X 1)
Direct Indirect		(d)	 -	 -	  -	   X 2)
Direct Indirect Long	[d]	 -	 -	  -	   X
Direct Indexed Indir	(d,x)	 -	 -	  -	   X 3)
Direct Indir Indexed	(d),y	 -	 -	  -	   X 3)
Direct Indirect Long,Y	[d],y	 -	 -	  -	   X
Block Move		axy	 -	 -	  -	   X


Notes:
 1,2,3)	On the 65SC802 and 65SC816, all Zeropage addressing modes have been
	 replaced with Direct Register (with Offset).


  1.7  Interrupts

 VICE divides all exceptions, including interrupts, to the following 24
 classes, allowing one pending event per class at a time:

   Software

	I_BRK			Software interrupt


   VIC

	I_LIGHT_PEN	
	I_SS_COL		Sprite to sprite collision
	I_SB_COL		Sprite to background collision
	I_RASTER		Raster compare


   CIA 1 / VIA 2 IRQs

	I_CIA1FL		CIA 1 FLAG1,
				VIA 2 FLAG1 (I_CIA1CB1),
				VIA 2 FLAG2 (I_CIA1CB2),
				VIA 2 FLAG3 (I_CIA1CA1),
				VIA 2 FLAG4 (I_CIA1CA2)

	I_CIA1SP		CIA 1 serial port
	I_CIA1TOD		CIA 1 TOD alarm
	I_CIA1TA		CIA 1 timer A
	I_CIA1TB		CIA 1 timer B


   CIA 2 / VIA 1 NMIs

	I_CIA2FL		CIA 2 FLAG 1,
				VIA 1 FLAG1 (I_CIA2CB1),
				VIA 1 FLAG2 (I_CIA2CB2),
				VIA 1 FLAG3 (I_CIA2CA1),
				VIA 1 FLAG4 (I_CIA2CA2)

	I_CIA2SP		CIA 2 serial port
	I_CIA2TOD		CIA 2 TOD alarm
	I_CIA2TA		CIA 2 timer A
	I_CIA2TB		CIA 2 timer B


   PET PIA / VIA Interrupts

	I_VIA1T1		PET via1 t1
	I_VIA1T2		PET via1 t2
	I_VIA2T1		PET via2 t1
	I_VIA2T2		PET via2 t2


   Special Exceptions

	I_SPECX			Special "interrupt" for x_loop
	I_RESTORE		Restore key NMI
	I_RESET			Reset in startup



  1.8  Interrupt Sources

 CIA (MOS 6526) does not clear pending interrupts when writing Register 0D (13)
 but only when read.

 VIC-II clears IRQs when active interrupt sources are disabled by writing to
 D01A.

 On a PET the IRQs come directly from the video retrace timing circuitry and
 not trough the VIA.



  2. MEMORY

  2.1 System ROMs

 The description below is from the "c64-kernel.diffs" by Marko Makela, which
 also contains exact list of all differences between the ROM versions.
 It is available via FTP on ftp.funet.fi:/pub/cbm/documents/
 or x2ftp.oulu.fi:/pub/cbm/docs/ directory.


  2.1.1 Commodore 64 KERNAL ROM versions.

 The Commodore 64 KERNAL revisions are: R1, R2, R3 and the Commodore SX-64
 and the Commodore 4064 ROMs.  The chronological order must be R1, R2, 4064,
 R3 and SX-64.

 The KERNAL ROM R1 was obviously used only in early NTSC systems.
 It lacks the PAL/NTSC detection, and always uses white color while
 clearing the screen.  The white color feature is from the VIC-20
 ROM, but the VIC had a white background by default.  Thus, this
 feature can be listed as a bug.  The CIA 1 timer A will always
 divide the system clock through $411C == 16668.  The other ROMs use
 the values $4026 an $4296, depending on the system version
 (PAL/NTSC), so their interrupt frequency is 985248 Hz / 16422 ==
 59.996 Hz or 1022727 Hz / 17046 == 59.998 Hz.  Note that both
 clock divisor values differ from the value used in the KERNAL R1.

 The PAL/NTSC flag ($2A6) affects the RS-232 timer settings as well.
 It seems that the new RS-232 tables for the PAL have been created on
 the upper BASIC interpreter area ($E000--$E4FF), from the address
 $E4EC on. Surprisingly also the original NTSC tables have been
 changed.  Very probably the units running the KERNAL R1 had a slower
 clock frequency.  Extrapolating from the interrupt timer values,
 they ran at 1.0000 MHz.  Now this makes sense, since the first
 (NTSC) video chips had 262 lines per frame and 64 cycles per line.
 The frame rate was thus 1 MHz / 262 / 64 == 59.637 Hz.  The newer
 NTSC units run at 1022727 Hz and draw 263 lines per frame and use 65
 cycles per line.  This produces a frame rate of 59.826 Hz.  Well,
 now it is very obvious that there has been at least one mother board
 type that has only been used on NTSC units.  Probably the processor
 clock was created from a 8 MHz chrystal frequency, which served as
 the dot clock.  The latter NTSC units generate the processor clock
 by dividing the chrystal frequency of 14318181 Hz by 14, and the dot
 clock will be generated by octacoupling the processor clock.

 The PAL systems have been developed later, and they always run at
 the same clock frequency, 17734472 Hz / 18.  The frame rate has
 always been 17734472 Hz / 312 / 63 == 50.125 Hz on those puppies.

 The changes in the latter ROM revisions were mainly cosmetical.
 There were some bugs corrected in the R3 revision, though.


  Number:  901227-01	Commodore 64 KERNAL R1, $FF80 content $AA
           901227-02	Commodore 64 KERNAL R2, $FF80 content $00
           901227-03	Commodore 64 KERNAL R3, $FF80 content $03
           ??????-??	SX-64 or DX-64 KERNAL, $FF80 content $43
           ??????-??	4064 aka PET 64 aka Educator 64, $FF80 content $64



   C64 R3 and R2 kernal compatibility

 Usually, R3 kernal users only use $0286 (#646) to set the color for $D800.
 Below is a code that works on both R2 and R3, but R1 kernels always fill with
 white. You have to fill the colour memory manually on those.

	LDA #$(colour)
	STA $D021	; For Kernel R2
	STA $0286
	JSR $E544	; Clear screen


From: firefoot@omni.voicenet.com (Ivan)

 I always thought it was best to just go for the direct route and waste a 
 few bytes (but save a few cycles) and just do it myself:

		lda #(color)
		ldx #0
	label	sta $d800,x
	        inx
	        bne label
		inc label+2
		ldy label+2
		cpy #$dc
		bne label

--
Firefoot/Style
firefoot@style64.com


 

   2.1.2 Commodore 128 ROM versions.

 There are 2 BASIC releases - 1985 and 1986 - for the Commodore 128.

  Number: 318018-02 and 318019-02	C128 BASIC 7.0, 1985 release
	  ?		?		C128 BASIC 7.0, 1986 release




   C128 Memory Configuration

  (For the C64 configuration, see 64doc.)


	Higher Priority						Lower Priority
FFFF --------------------------------------------------------------------------
			Kernel		F Int Hi	F Ext Hi	RAM
FF00-FF04		MMU		MMU		MMU		MMU
			Kernel		F Int Hi	F Ext Hi
E000
	(BIOS)	I/O	Chargen		F Int Hi	F Ext Hi	RAM
D000
			Editor		F Int Hi	F Ext Hi
C000 --------------------------------------------------------------------------
			Monitor		F Int Lo	F Ext Lo	RAM
B000
			Basic Hi	F Int Lo	F Ext Lo	RAM

8000 --------------------------------------------------------------------------

			Basic Lo					RAM


4000 --------------------------------------------------------------------------

			Bankable RAM


0400 --------------------------------------------------------------------------
			Common RAM
0000

	Common RAM can be located at bottom, at top, or both. Possible
	sizes are 1K, 4K, 8K, and 16K.
	BIOS is for CP/M.

 Terminology:
	MMU	Memory Management Unit MOS 8722.
	F Int	Internal Function ROM. Function ROMs are third-party products.
	F Ext	External Function ROM in the Expansion Port
	Chrgen	The font images
	Editor	All display control routines
	Monitor	The Machine Language Monitor inbuilt in the C128
	Basic	The Basic 7.0 interpreter ROM
	Kernel	The Kernel ROM



   2.2 I/O Decoding


	VIC-20

 1) the VIAs 6522

 Apparently, VIA#1, the one which deals mainly with the user port, is
 selected by this address pattern:

 address bit: 0123 4567 89AB CDEF
               rrrr 1??? ??00 1001

 where 'r' means that the bit is used to select the registers 
 and '?' means that the bit is *insignificant* (not wired to the chip).

 Consequently, the chip is selected by the addresses: $9xyr
 where x = 0..3
       y = 1,3,5,7,9,B,D,F 
 and   r = 0..F

 Similarly, VIA#2 is selected by:

 address bit: 0123 4567 89AB CDEF
              rrrr ?1?? ??00 1001

 =>    x = 0..3
       y = 2,3,6,7,A,B,E,F
 and   r = 0..F

 Thus, there are address regions where you can access the registers
 of *one* of the VIAs, some with *both*, and some with *none* of them.

 For instance, the addresses $9110, $9310, $9350 should address the
 *same* register of VIA#1.


 2) the VIC 6561

 The wiring of this chip is less obvious to me than the others':

 The 13 lowest address bit lines (A0-A12) are wired directly to
 the A0-A12 pins of the 6561 and the BLK4 select line [ which is
 obviously the same as ( (!A13) & (!A14) & A15 ) ] is wired to
 pin A13.

 Thus the VIC 6561 has access to the entire Block4 ($8000-$9FFF).
 What that means depends on its internal features.

 8000 - 8FFF is Character ROM, so I don't expect it to show up there.


 Altough the VIC-I only has 15 registers, there are duplicate images of
 them in the VIC-20 -- that way Commodore saved a lot in decoders.
 Both the VIA locations +10 and +20 support that.


	9000 10 20 30 40 50 60 70 80 90 A0 B0 C0 D0 E0 F0
  VIC	   x  x  x  x  x  x  x  x  x  x  x  x  x  x  x  x
  VIA #1      x     x     x     x     x     x     x     x
  VIA #2         x  x        x  x        x  x        x  x


	9100 10 20 30 40 50 60 70 80 90 A0 B0 C0 D0 E0 F0 etc.
  VIC
  VIA #1      x     x     x     x     x     x     x     x
  VIA #2         x  x        x  x        x  x        x  x



  2.3 C64 vs. 128 incompatibility

 On the C128 'No Key' returns 88 instead of 64. If a program counts on this,
 press down the Help key.

 In the Peripheral Port described earlier, there is one new bit in use.
 Use the Capslock or ASCII/CC key to get correct value.


	Differences Between C64 and C128 I/O

	D500-D50B	MMU
	D600-D601	VDC
	FF00-FF05	Preconfiguration Registers

 Since there are several new chips inside the C128, some shadow images that
 appeared on C64, are no longer there. Writing to such a location may cause
 undesired effects.

 Also, there are 2 more registers on the VIC-IIe chip, and a common mistake
 to write past the chip in initialization probably loop crashes your program.


From: uhaen92@hvdc.hv.se (Ulf Harnhammar)
Subject: Running 64 programs on a 128

Alex Stivala (alex@cairo.anu.edu.au) wrote:
: Yes, one of the Monty Mole games (the exact name escapes my memory, I
: can check later if you want, I still have it at home) runs fine on a 64,
: but on a 128 in 64 mode, you get a blank screen, and some music (I
: think), and you can't seem to do anything with it. It even says on the
: box that it is not compatible with the 128.

: I'm not sure why this is. Could it be that it messes with that location
: that puts a 128 in 64 mode in 2 MHz mode, blanking the VIC screen?


Yes, that's my experience. On a 64, reading the address $D030 gives a value of
#$FF, and when you store that into a 128, it switches on both 2 MHz and another
bit that is used for testing (can be used for making some weird grey colours
mode too). To make everything run on all computers, you should either not store
anything to $D030, or store the value #$FC, that signals that everything is
normal on a 128. This does also apply for the mirror areas, $D070 $D0B0 $D0F0
and so on.

I have a 128, and I've seen the most stupid coding mistakes concerning $D030
that you would imagine, for example:

        LDX #$10
LOOP    LDA TABLE,X
        STA $D026,X
        DEX
        BNE LOOP

This will run on any computer, if you just correct the LDX statement.




  2.4 REU -- Ram Expansion Unit

 Total 3 different sizes of REUs are supported: sizes available are 128, 256
 and 512 KB.


 Using REU in Basic V7.0

  SYNTAX
	FETCH	Transfer from RAM expansion to memory

	FETCH #bytes, intsa, expsa, expb


	STASH	Transfer from memory to RAM expansion

	STASH #bytes, intsa, expsa, expb


	SWAP	Swap memory with RAM expansion

	SWAP #bytes, intsa, expsa, expb


  DESCRIPTION
	bytes	number of bytes to transfer (1-65535)
	intsa	start address in memory (0-65535)
	expsa	start address in RAM expansion (0-65535)
	expb	RAM expansion bank number (0-15)




From: dschmoll@nyx10.cs.du.edu (David Schmoll)
Subject: RAMDOS question


> is it possible to make RAMDOS only use part of an REU?

Ramdos can be easily fooled to use less than the entire REU, but it
must be done in banks. There was an article by Fred Bowen in TC128
issue 23 that detailed how. BTW, REU memory is accessed from bank 0 up.

I'm not going to type in the entire program but I'll try to give you
the relevant part. (f=0 if 64/f=1 if 128). A new copy of Ramdos was
included in the article.

if f=0 then ml=25344
if f=1 then ml=8960

the ML has also been loaded at this point, and the hack only works on
V4.x version of the ML.

9180 rem verify size of REU
9200 nb=0
9210 if f=0 then sn=32317:b=24837:v=25741
9220 if f=1 then sn=15983:b= 8453:v= 9357
9230 for i=0to2:v$=v$+chr$(peek(v+i)):next
9240 print "ramdisk version "v$" loaded":sys ml+12:print
9250 if left$(v$,2)="4." then sys sn::nb=peek(b)
9270 return

input "number of banks";pb

220 if f = 0 then poke sn+3,pb :pokesn+4,76 :pokesn+5,134 :pokesn+6,126
225 if f = 1 then poke sn+3,pb :pokesn+4,76 :pokesn+5,184 :pokesn+6,62

This fools the sniff routine to think it has less than it really
does, and from here on just proceed with the normal Ramdos initialization.


   Wordprocessors that use the REU

   C128:
	Pocket Writer 2 and 3
	Paperclip 3
	The Write Stuff
	Geowrite
	ZED-128


From: count0@mail.bremen.pop.de (Count Zero)
Subject: Re: Checking the presence of a 17xx REU.

As far as my docs just told me

00 in $df00 expresses 128 K
01 in $df00 expresses 512 K

The best way to ensure there is a REU present, I would write something
to the REU, read it back and check out if it returned ... Dumb way I guess :)


 GeoRam


 GeoRAM is a large external 512K RAM cartridge that banks RAM into a 256
 byte page.  Commodore had 17xx REUs with DMA.  CMD/PPI had the
 RAMDrive, and CMD is still producing the RAMLink.  SSI might still be
 selling the REU Clone.  These are all external hardware.

alan.jones@qcs.org

From: Bruce McFarling <brmcf@utkux1.utk.edu>
Subject: GEORam Register Question

	I've been going through my register information, and I have 
 gotten down that the GEORam (and BBG) work with registers in DFFE and 
 DFFF, and when selected the current binary page appears at DE00 ... 
 DEFF.  However, I have entirely lost the specification of what those 16 
 magic bits in DFFE and DFFF *are*.  As far as I recall, DFFE is the 
 second byte to select the binary page, and this extends for the lower
 bits of DFFF, with the upper bits of DFFF used to toggle the RAM in and out.
  Is that right?  For 512K, there would have to be a minimum of 4 
 bits in DFFF dedicated to memory address: is that all?  And what 
 specifically do the upper bits do?
 

Bruce McFarling, Knoxville
brmcf@utkux1.utk.edu



  2.5 Internal Memory Expansions

  2.5.1 VIC-20

 It is possible to build writeable VIC-20 game cartridges using SRAM chips
 instead of PROMs -- even internally.

 Instructions for the 32K Internal VIC-20 Memory expansion are located at
	ftp://x2ftp.oulu.fi:/pub/cbm/docs/VIC-32K-expansion



  2.5.2 C64 RAM expansion


 Pessi's RAM expansion.  This expansion replaces the
 64K RAM with 256K RAM which is logicaly partitioned in 16K blocks.  Any
 four blocks can be mapped into the 64K address space.  Pessi also has a
 RAM expansion for the C128 wich can have up to four banks of 256K RAM
 (1024K total).  These RAM expansions do involve additional hardware,
 but is installed internally.

 For more information on C64 Memory expansions, see
	The comp.sys.cbm General FAQ
	ftp://ftp.funet.fi:/pub/cbm/documents/256kB/


	Expansion Controller  MC6821 PIA

	+-------------+-------------+
  DF80	|  Segment 1  |  Segment 0  |		Segment 3	C000 - FFFF
	+-------------+-------------+		Segment 2	8000 - BFFF
  DF81	|  Control Register A       |		Segment 1	4000 - 7FFF
	+-------------+-------------+		Segment 0	0000 - 3FFF
  DF82	|  Segment 3  |  Segment 2  |
	+-------------+-------------+
  DF83	|  Control Register B       |
	+-------------+-------------+


 Bosacki also has C64 RAM expansion designs of 256 and 512K, see
 Transactor 9-6.  Fritzterm is the only application than I know of that
 uses Bosacki RAM.


 2.5.3 C128

 On X128 emulator the internal RAM can be expanded to 256KB.

 For more information on C128 Memory expansions, see
	The comp.sys.cbm General FAQ
	ftp://ftp.funet.fi:/pub/cbm/documents/1028/


 Twin Cities 128 - Issue #32 - July 92 has an article Internal Function Ram
 by Richard Curcio. A full explanation with mechanical and schematic diagrams.



  2.6 Emulator Detection

 X64/128 implements optionally the Emulator Detection method introduced by
 Wolfgang Lorentz. However, the program does not run on C128, thereby
 leaving that in half-way.

 The following  Emulator ID message is provided on VICE:
	VICE 0.11
	(C) 1993-96 j.sonninen/t.rantanen/j.valta/e.perazzoli/a.fachat.


 The ID is constructed as follows:

	DFA0-	   57248-	Version and Copyright Message

	DFFC-DFFD  57340-41	The emulator version number,
				 currently 0011 for version 0.11.

	DFFE	   57342	Identification key: "V" for VICE.

	DFFF	   57343	Toggles between 55 and AA (85 and 170 dec)



  2.7  The C128 MMU


 C128 MMU  8722


D500		Configuration Register (CR)
	7-6	RAM-select 0-3
	5-4	High RAM/ROM
			00 System ROM (Kernel, Edit)
			01 Internal Function ROM
			10 External Function ROM
			11 RAM
		  NOTE: I/O overrides all of these.

	3-2	Mid RAM/ROM
			00 System ROM (Basic HI)
			01 Internal Function ROM
			10 External Function ROM
			11 RAM

	1	Lo RAM
			0  System ROM (Basic LO)
			1  RAM

	0	C.GEN
			0  I/O
			1  ROM/RAM


D501		Preconfiguration Registers
D502
D503
D504

D505	7	40/80 read only
	6	C64 Mode (0 = C128)
	5	EXROM: C64 (1 = C128) read only
	4	GAME:  C64 (1 = C128) read only
	3	FSDIR: Fast Disk Transfer Direction
	2-1	-
	0	Z80/8502

D506		RAM Configuration Register (RCR)

	7-6	Video-Bank
	5-4	-
	3	Shared RAM Hi
	2	Shared RAM Lo
	1-0	Shared RAM Size: 00 = 1K, 01 = 4K, 10 = 8K, 11 = 16K

D507		Zero Page Pointer Lo

	7-0	A15-A8

D508		Zero Page Pointer Hi

	7-4	-
	3-2	A19-A18 (Used in 1MB System)
	1-0	A17-A16	(256K System)

D509		Stack Page Pointer Lo
D50A		Stack Page Pointer Hi

D50B		MMU Version Register

	7-4	Bank Version (2 = 128K)
	3-0	MMU Version



	Default Memory Configurations

	Bank   FF00    Free RAM Space	RAM I/O  ROM

	 0	3f	0000-ffff	 0
	 1	7f	0000-ffff	 1
	 2	bf	0000-ffff	 2
	 3	ff	0000-ffff	 3

	 4	16	0000-7fff	 0  I/O  Int
	 5	56	0000-7fff	 1  I/O  Int
	 6	96	0000-7fff	 2  I/O  Int
	 7	d6	0000-7fff	 3  I/O  Int

	 8	2a	0000-7fff	 0  I/O  Ext
	 9	6a	0000-7fff	 1  I/O  Ext
	10	aa	0000-7fff	 2  I/O  Ext
	11	ea	0000-7fff	 3  I/O  Ext

	12	06	0000-7fff	 0  I/O  Kernal Int_Rom_Low
	13	0a	0000-7fff	 0  I/O  Kernal Ext_Rom_Low
	14	01	0000-3fff	 0  Char Kernal Basic
	15	00	0000-3fff	 0  I/O  Kernal Basic




  3. C128 CP/M OPERATING MODE

  3.1 Zilog Z80 CPU
 

	The Zilog Z80 Programming Model


	  Registers			Alternate Registers

	15      8 7      0		15      8 7      0
	+--------+--------+.............+--------+--------+
	|   A    |   F    |  EX AF,AF'	|   A'   |   F'   |
	+--------+--------+.............+--------+--------+
	|   B    |   C    |		|   B'   |   C'   |
	+--------+--------+		+--------+--------+
	|   D    |   E    |  <- EXX ->	|   D'   |   E'   |
	+--------+--------+		+--------+--------+
	|   H    |   L    |		|   H'   |   L'   |
	+--------+--------+.............+--------+--------+


	Special Purpose Registers	Status Register F
	+--------+--------+		+-----------------+
	|   I    |   R    |		| S Z - H - P N C |
	+--------+--------+		+-----------------+
	|   h   IX    l   |
	+-----------------+		    S = Negative
	|   h   IY    l   |		    Z = Zero
	+-----------------+		    H = Half byte Carry
	|       SP        |		    V = Parity/Overflow
	+-----------------+		    N = Add/Subtract Flag
	|       PC        |		    C = Carry
	+-----------------+



	How Z80 Programming Differs From 6502

	Byte Order

 Both processors use the same byte order, namely Least Significant Byte (LSB)
 first.
 What confuses die-hard C64 hackers is using the 16-bit instructions on Z80.
 Surprisingly enough, the MSB is loaded to the first register of any register
 pair. I.e. ld bc,D505 loads B with value D5 and C with 05.


	Denoting Addressing Modes

 First, it's important to make difference between the symbols identifying the
 addressing modes on each processor.
 While 6502 uses '#' to denote Immediate parameter, there's no prefix on Z80
 operand. Respectively, what seems like an Indirect addessing to the average
 6502 programmer, actually is the Absolute addressing mode.

 The advantage of this style is that also registers can be referenced the same
 way as absolute addresses. On the other hand, it's not so clear to read as
 with separate Load, Store and Transfer commands on 6502.



  3.2 CPU Comparison

 
comp.sys.cbm #16533
From: aa601@cfn.cs.dal.ca (George W. Taylor)
Subject: Re: Z80 mode
Date: Mon Oct 17 20:57:41 CDT 1994
 
Mike Gordillo (621126@mercury.utb.edu) wrote:
 
: LD   DE,TAB2  ; load, (D,E) = destination address
: LD   HL,TAB1  ; load, (H,L) = source address
: LD   BC,100   ; load, (B,C) = number of words
: LDIR
 
: The transfer is made by LDIR and the stats for this little exercise 
: should be 20+16+20+2095 total cycles.  Ok, so roughly 21 cycles per byte 
: and assuming 4 Mhz for the Z80 in the 128, roughly 5 microseconds per byte.
: What would be the equivalent code (using a loop no doubt) and stats for 6502?
--
So, I have 10.5 cycles on average to move 100 bytes ( measured in 8502 at 
2MHz time).
 
Straightforward code would be:
 
     ldx #99
ldir lda tab1,x
     sta tab2,x
     dex
     bpl ldir
 
This takes 13 cycles per loop.. no good.
Easy to fix:
 
     ldx #49
ldir lda tab1+50,x
     sta tab2+50,x
     lda tab1,x
     sta tab2
     dex
     bpl ldir
 
2 bytes moved in 21 cycles or 10.5 cycles average.  The overhead is 1 cycle.
Already I have beat Z80 code.  In fact the 128 has a special feature to 
do even better:  a relocatable zero page and stack.
I don't know exactly how to move the zero page, but it's something like this:
 
     lda #>tab1
     sta stack_page_high
     lda #>tab2
     sta zero_page_high
     ldx #49
     txs
ldir pla ;read tab1,sp and decrement sp
     tsx
     sta <tab2,x
     lda tab1+50,x
     sta <tab2+50,x
     bpl ldir
 
18 cycles for two bytes, so 9 cycles per byte.  Tab1 must start at a page 
boundary, and tab2 must be contained within a page.
I can't remember which is 3 cycles; pla or pha, but the routine can be 
arranged to use the faster one, so it can be made to run in 9 cycles 
anyhow.  LDIR is actually not the fastest way to move memory.  I suggest 
setting the stack to tab1 and using POP BC then storing a word at a time 
to tab2.. hmm.. I don't remember enough z80 to know if this will end up 
faster.  I was thinking ld (HL),bc and sub l, #1 and jp nz loop.
Even the fastest Z80 instructions can be beat.  RRCA takes 4 cycles while 
ROR takes 2 cycles.
 
 
Z80 vs 8502 (6502 series)    -- From 500 C-128 Questions answered.
 
 
The Z80 has some advantages over the 8502.
 
1) It has a 16-bit stack pointer.  The stack can be put anywhere in memory and
can be of unlimited size.  The 8502 has a one page stack size at a fixed
location.  Programmers must work harder to develop software stacks when
implementing languages such as C in C-128 mode.
 
(Note : Very good C packages in CP/M.  Lousy C packages in C64/128. )
 
2) The Z80 can do 16-bit math.  The 8502 only does 8-bit math.
 
3) The Z80 has *lots* of registers.  The 8502 makes up for this by using zero
page pointers.  Moving data from one register to another under the Z80 can be
done quickly and easily.  However, the 8502's zero page with its 256 bytes
allows certain freedoms.
 
4) The Z80 has somewhat better interrupt capabilities than the 8502.  One Z80
mode allows interrupt vectors in page 0 for hardware interrupts.
 
5) The Z80 is generally recognized as having a richer instruction set than the
8502.  The Z80 has string instructions to move and compare entire ranges of
memory in one instruction, a large set of bit manipulation instructions to
test, set and clear single bits in a byte and more powerful I/O instructions.
 
 
This makes it sound like the 128's native mode could have dispensed with the
8502 altogether.  Does the 8502 have some comparative advantages?
 
-- Just as CP/M mode runs better for the included Z80, 64 mode pretty much
requires a 6502 family CPU.  Furthermore, the 8502 does have a few advantages
over the Z80 processor.
 
1) The 8502 has true index register capabilities while the Z80 has only
limited index register capabilities.
 
2) Since the 6502 is a product of Commodore-owned MOS technologies, the 8502
has cost advantages over the externally produced Z80.
 
3) By the time of the C-128's announcement, the 6502 family was a
substantially more popular CPU than the Z80.  Popularity means that there are
more programmers familiar with maximizing the 6502's architecture.
 
4) The 128's native mode sound and graphic abilities require the CPU to
interact with the system in sophisticated ways.  The kernal routines existed
to do this with a 6502, but would have to have been developed to accomplish
the same thing with the Z80.
 
(Note : Mr. Steve Goldsmith has developed decent libraries for gphx/sound/io
under Turbo Pascal and Hi-Tech C.)
----------------------------------
 
From: csbruce@ccnga.uwaterloo.ca (Craig Bruce)
Subject: Re: z80 - 8502 addition
Date: Tue Oct 11 12:18:37 CDT 1994
 
Yo!
 
621126@mercury.utb.edu (Mike Gordillo) writes:
 
>Z80 vs 8502 (6502 series)    -- From 500 C-128 Questions answered.
> 
>The Z80 has some advantages over the 8502.
>[...]
> 
>-- Just as CP/M mode runs better for the included Z80, 64 mode pretty much
>requires a 6502 family CPU.  Furthermore, the 8502 does have a few advantages
>over the Z80 processor.
>[...]
>(Double Note : Z80B clocks faster but Z80 instr are slower to execute)
 
A long time ago I tried out the Z80 mode myself.  I did the CPU switch stuff
from that Transactor magazine and I was all enthused about doing things like
moving data from place to place quickly with the Z80's block move feature.  I
was disappointed, though, when I tried it and found out that the 8502 can do
the job faster in a program loop.
 
The reason is that it takes like eight internal revs of the cam for the Z80 to
perform one bus cycle.  The result is that the 2MHz 8502 can run rings around
the 4MHz(?) Z80 in the C128, despite the Z80's more powerful instruction set.
I haven't used the Z80 since.


-Craig Bruce
csbruce@ccnga.uwaterloo.ca
"A policeman's job is only easy in a police state." -- Orson Welles

---------------------------
 
From: 621126@mercury.utb.edu (Mike Gordillo)
Subject: Re: Z80 mode
Date: Sat Oct 15 01:13:16 CDT 1994
 
Hello,
 
        Earlier, Mr. Taylor suggested that the 6502 benefitted from 
pipelining while the z80 did not, thus the disparity in execution times 
for similar instructions.  Well, I scoured the heavens for some z80 
documentation and I found that the z80 does seem to engage in 
fetch/execute/fetch "pipelining" as does the 6502.  So now I'm left 
wondering again why z80 ops run from 3 to 21 cycles while 6502 churns 
from 2 to 7.  Ok, just to get some hard data on the matter, I'd like 
someone to illustrate the 6502 equivalent of the following:
 
-------------------from various Z80 texts---------------------
 
        The Z80 has a special group of instructions designed to move 
tables of data and locate entries within the tables.  These are the four 
table-move instructions LDI, LDIR, LDD, and LDDR.  Each one requires the 
following presets for the registers.
 
(D,E) - Address of destination
(H,L) - Address of source
(B,C) - Number of words to be transferred
 
Every time the Z80 executes the block transfer instruction, these 
registers are updated.  LDIR, for example, increments the (D,E) and (H,L) 
registers and decrements the (B,C) registers after each move.  LDIR 
continues to transfer data until (B,C) is equal to zero.  With this in 
mind, we shall try a little experiment.  Let there be two tables, TAB1 
and TAB2, each with 100 bytes of data.  We want to transfer data between 
the tables, so we code
 
LD   DE,TAB2    ; load, (D,E) = destination address
LD   HL,TAB1    ; load, (H,L) = source address
LD   BC,100     ; load, (B,C) = number of words
LDIR
 
The transfer is made by LDIR and the stats for this little exercise 
should be 20+16+20+2095 total cycles.  Ok, so roughly 21 cycles per byte 
and assuming 4 Mhz for the Z80 in the 128, roughly 5 microseconds per byte.
What would be the equivalent code (using a loop no doubt) and stats for 6502?
 
Mike
 
---------------------------------
 
comp.sys.cbm #16457 (37 more)
From: csbruce@ccnga.uwaterloo.ca (Craig Bruce)
Subject: Re: Z80 mode
Date: Sat Oct 15 17:02:36 CDT 1994
 
Yo!
 
621126@mercury.utb.edu (Mike Gordillo) writes:
 
>LD   DE,TAB2   ; load, (D,E) = destination address
>LD   HL,TAB1   ; load, (H,L) = source address
>LD   BC,100    ; load, (B,C) = number of words
>LDIR
>
>The transfer is made by LDIR and the stats for this little exercise 
>should be 20+16+20+2095 total cycles.  Ok, so roughly 21 cycles per byte 
>and assuming 4 Mhz for the Z80 in the 128, roughly 5 microseconds per byte.
>What would be the equivalent code (using a loop no doubt) and stats for 6502?
 
Are you sure that the Z80 runs at an effective speed of 4 MHz?  I thought it
was more like 2 MHz (or maybe, really, even slower).  The 6502 can do the
same job with:
 
   ldx #100-1        ;2 cycles
-  lda tab1,x        ;4 (assuming no page boundary gets crossed)
   sta tab2,x        ;5 (assuming no page boundary gets crossed)
   dex               ;2
   bpl -             ;3 (normally)
 
This makes the loop time 4+5+2+3 = 14 cycles per byte, for a total of 14*100+2
or 1402 cycles.  At 2 MHz, this works out to 6.8 microseconds per byte.  I am
quite sure that the C128's Z80 can't beat this.
 
Keep on Hackin'!
 
-Craig Bruce
csbruce@ccnga.uwaterloo.ca
"Bruce's Law: Governments are not generally opposed to acquiring more power."
-----------------------------------------
 
comp.sys.cbm #16479 (16 more)
From: fox@netcom.com (Fuzzy Fox)
Subject: Re: Z80 - 8502 (part ii)
Date: Sun Oct 16 04:26:12 CDT 1994
 
621126@mercury.utb.edu (Mike Gordillo) writes:
 
>Oh ye gods of hardware that never actualizes, what say you on
>(practical) circuitry allowing 8502 and z80 a modicum of concurrency?
 
The only way I can see this happening is if you put them on separate
busses.  They can't share the same bus at the same time.
 
Hmm, I take that back.  If you were to speed up the bus significantly,
they could try to multiplex bus access.  But that takes faster RAM and
probably completely different glue logic.  Would the resulting machine
still be a C128?  :)
 
-- 
  Fuzzy Fox        | "The aardvark is really a curious creature;
fox@netcom.com     |  If you're an ant, he's likely to eatcher.
<http://mikey.     |  Although his long nose makes him look rather hideous,
 convex.com:8080/> |  He's still listed first in the encyclopideous."
 
---------------------------------
 
From: "George W. Taylor" <aa601@cfn.cs.dal.ca>
Subject: Re: Z80 mode
 
 
: George Taylor,
 
:       The Z80 routine I gave is a generalized block transfer routine 
: (more than 256 elements).  LDIR is the fastest method that I have seen 
: so far.  I don't know if zero page plays the same role for the z80 as
: it does for 6502, though... ?
 
: Mike 
 
--
Hi,
no, zero page mode is a special addressing mode applicable only to 6502.
I thought I found a faster method than LDIR, but I would have to look 
into it again, with a list of opcodes and times in front of me.
As for a general 6502 routine to move any number of bytes to any 
location, I think a program could be made that would CREATE a specific 
routine just to move those bytes efficiently.  Then the results I gave 
you would always apply, ie, 9 cycles per byte.  There would be some 
overhead for constructing the routine, but for more than 100 bytes or so 
it would always be faster.  Even so, a check can be made for small moves 
and branch to a routine than is optimized for small moves.
Reply to me and I'll send you back a Z80 digi play routine sometime.
Later
(if you have any more Z80 challenges, let me know, I'll try to beat them 
with 6502 code :)
Btw, I heard there is a way to run Z80 and 6502 at once, but of course 
due to the reasons I explained in a posting before, both CPU's will 
immediately crash, because they are accessing the bus at the same time.
While Z80 enabled switch to c64 mode.
 

The following is quoted from FidoNet:
 
subj: Cp/M & Z80
from: Dave Kennedy
on  : Sun 18-Dec-1994 11:05p
 
 
  CPU         MHz
 =================
  Z80         2.5
 *Z80A        4
  Z80B        6
  Z84C00-4    4
 
 * Used in C=128 & C=128D according to C=128 INTERNALS (p182), C=128
   PROGRAMMER'S REFERENCE GUIDE (p723; U10 on schematic 310378) and
   C=128D SYSTEM GUIDE (p395).
   {In C=128D technical specifications it is listed as 2MHz}
 
---
This is ODD... I have never seen anything but Z80B's in C128's.



From: NEUS@timsg.csc.ti.com (Mike Neus)
Subject: Re: Z80 in 128
Date: 10 Jul 1995 16:34:55 GMT


621126@mercury.utb.edu (Mike Gordillo) says:
>
>  The "real-world" speed is less than 2 Mhz.  Unfortunately, I've tested
>this fanatically, or rather *angrily*, and it seems to be running 1.5 Mhz
>or so.  This is the effective system speed.  My *opinion* is that the bus
>gets shoved into 1 Mhz every now and then, and if the chip is actually at
>2 Mhz, it doesn't even dance to it's own beat so to speak.  I'd like to
>finally clear the S/N ratio on this one.  *Everyone* knows C= crippled
>the bastard, but come on, let's have some tech files or reference data at 
>how they did it...and laugh or cry at what we find... (It might also 
>be nice to hear about Von Ertwine's port-over of CP/M itself...)

The 128 Programmers Reference Guide explains it all.  The Z80 is indeed clocked
at 4MHz, but to enable the 40 column screen, the clock is stopped every two
cycles (when phi-2 is low?).  This reduces the speed of the Z80 to 2MHz.  On
top of this is the VIC DMA's, which slows the Z80 further.  Turn the VIC off
as a display chip and you probably will get 2MHz.  I'm not sure if the clock
stretching cripple applies to the Z80 when it accesses I/O, but I don't think
so.

Lets not forget Commodore crippled the 8502 in the same manor when the VIC is
the display chip, and slows the 2MHz clock to 1MHz 50% of the time when 
accessing I/O chips.

I find your anti-Z80 "crippling" statement amusing.

=====================================================ooO=(_)=Ooo==============
  Mike Neus                "Error reading FAT record.  Try the SKINNY one?"
  NEUS@TIMSG.CSC.TI.COM      Visit the TI home page at http://www.ti.com



 I used both oscilloscope and frequency counter:
	Z80 is clocked at average 1.97051MHz, (slow and fast, Z80 inactive)
	8502 -"-  average 0.98525MHz (slow) and  1.89050MHz (fast).

 The Z80 clock signal looks like this:
	       ,__.  ,__.              ,__.  ,__.
	       |  |  |  |              |  |  |  |
	_______|  |__|  |______________|  |__|  |________



  3.3  I/O Accessing

 Z80 uses separate I/O address space via IN and OUT instructions. On hardware
 level there's Memory/IO output signal is provided to control the system.
 (On C128 this output is not used.)

 However, since the IO has always been memory-mapped on CBM computers, this
 feature only saves us from banking in the IO.

 It has been little known feature that the IO address provided is 16 bits wide
 any time the C register is used for address. Thus, e.g. IN A,(C) actually
 performs IN A,(BC).
 (8080 copied contents of the lower 8 lines at upper 8 lines). This feature is
 only used in few designs.



 There are a couple of switching routines placed in the C128 RAM.
  Let's take a look:

 ---clip---
Z80

        FFD0  7B        SEI             :disable interrupts
        FFD1  A9 3E     LDA #$3E        :RAM for Z80
        FFD3  8D 00 FF  STA $FF00       :store
        FFD6  A9 B0     LDA #$B0        :switch on Z80
        FFD8  8D 05 D5  STA $D505
        FFDB  EA        NOP

 After returning from the Z80 program, the 8502 CPU continues at address
 $FFDC (65500). Then it returns to the calling program:

        FFDC  58        CLI             :enable interrupts
        FFDD  60        RTS             :return to BASIC

 The next routine it the opposite of the previous 8502 routine. This
 time it's naturally in Z80 machine language. One calls it on Z80 in order
 to return back to the 8502.


        FFE0  F3        DI              :disable interrupts
        FFE1  3E 3E     LD A,$3E        :correct memory set-up
        FFE3  32 00 FF  LD ($FF00),A
        FFE6  01 05 D5  LD BC,$D505     :BC register value
        FFE9  3E B1     LD A,$B1        :switch on 8502
        FFEB  ED 79     OUT (C),A
        FFED  00        NOP

--------------------------------- 
 
From: tratclif@oucsace.cs.ohiou.edu (Tracy Ratcliff)

 > I'm curious about this.  The above Z80 sequence seems to imply that the
 > Z80 in the 128 understands the 65xx memory mapping scheme.
 > However, the second code sequence makes it appear that it does not.
 > Why the difference?

 The OUT command in the second example prevents "bleed-thru" into the RAM
 below the I/O device.  In the first, since the MMU register is always
 visible in any standard memory configuration, you don't need to worry
 about bleed-thru.

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


 When the Z80 is swithed on via the routine at $FFD0, the Z80 continues
 by executing an another routine. Usually there is instruction "RST $08"
 in this location, making sure that CP/M is loaded. However, if you want
 to run your own program, you need to replace the "RST $08" instruction
 at $FFED with a jump instruction to your program.

 The program below makes all the necessary initializations discussed above,
 and runs a program which changes the border colour.

        10 BANK 0
        20 REM FFEE C3 00 30   JP 3000  (Z80)
        30 POKE 65518,195
        40 POKE 65519,0
        50 POKE 65520,48
        60 REM FFDC 58         CLI      (8502)
        70 POKE 65500,88
        80 REM FFDD 60         RTS      (8502)
        90 POKE 65501,96
        100 FOR I=12288 TO 12298
        110 READ A
        120 POKE I,A
        130 S=S+A
        140 NEXT I
        150 IF S <> 1691 THEN PRINT "VIRHE DATOISSA!": END
        160 SYS DEC("FFD0")
        170 GOTO 160
        180 DATA   1, 32,208,237,120, 61
        190 DATA 237,121,195,224,255

 ---clip---

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

From: Marko.Makela@HUT.FI

>> "Fuzzy" == Fuzzy Fox <fox@netcom.com> writes:


>> FFE1  3E 3E    LD A,$3E    :correct memory set-up
>> FFE3  32 00 FF LD ($FF00),A

Fuzzy> I'm curious about this.  The above Z80 sequence seems to imply
Fuzzy> that the Z80 in the 128 understands the 65xx memory mapping
Fuzzy> scheme.

I have never programmed in the Z80 mode, but this wouldn't be any surprise.
I've experimented with the 64 mode switching, and it is possible to use
the C64 mode in another bank (bank 1 instead of 0 (also banks 2 and 3 on my
expanded C128)), and you can even use the common memory scheme, for instance,
if you use bank 1, you can map $0000-$3FFF to bank 0 and $4000-$FFFF to bank 1.
And you can map the video chip memory accesses to any bank.

If I remember it correctly, the memory configuration register will be loaded
with $FF when you go to C64 mode, that is, the C128 ROMs are no more available.
I don't remember if I tried page relocation, but it might work as well.

BTW, I use the following code to switch to C64 mode:

20400 SEI
20401 LDA #$BE   ; $FE when I use bank 3
20403 STA $FF00  ; bank 2 RAM and I/O
20406 LDA #$80   ; $C0 when I use bank 3
20408 STA $D506  ; video bank 2, no common RAM
2040B LDA #$F7
2040D STA $D505  ; switch to C64 mode
20410 STA $1     ; set the memory configuration
20412 JMP($FFFC) ; jump to the reset vector


>> FFE6 01 05 D5 LD BC,$D505 :BC register value
>> FFE9 3E B1    LD A,$B1    :switch on 8502
>> FFEB ED 79    OUT (C),A

Fuzzy> However, this code sequence makes it appear that it does not.
Fuzzy> Why the difference?

What are you confusing?  The first Z80 code you quoted switched RAM bank 0
and left the I/O on.  That's why the MMU is accessible in the memory.
The $D505 register is used to select the processor.  The bit 0 might be the
processor select (1 is 8502).

When I have the time, I'll try to experiment with the Z80 ROM mapping.
I assume that the Z80 ROM is hard-wired to $0000-$0FFF, even if you fiddle
with the MMU registers.
 
        Marko

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

From: fox@netcom.com (Fuzzy Fox)
Subject: Re: 8502 - Z80B

Here's my question, stated more clearly:  We all know that the program
is trying to write $3E into $FF00, and $B1 into $D505, in order to
accomplish the switchover.  What I'm wondering is, why do we use a
direct store to memory in the first case, and the OUT instruction to
write in the second case?

Since the Z80 is sitting on the 8502 bus, it seems that all of its
accesses of that bus (i.e. memory-mapped I/O) should work exactly the
same way.  So the above code could be written as:

	LD A,$3E
	LD ($FF00),A
	LD A,$B1
	LD ($D505),A

Since most programmers don't try to actively make things more difficult
for themselves, I figure there is probably a good reason for the OUT
instruction, but I can't see it.  And also, is the reverse true?  Could
the first byte have been stored as 'OUT ($FF00),$3E' (using registers as
appropriate, of course)?


comp.sys.cbm #16260 (33 more)
From: Jim Stephenson <stephenson11@delphi.com>

>Here's my question, stated more clearly:  We all know that the program
>is trying to write $3E into $FF00, and $B1 into $D505, in order to
>accomplish the switchover.  What I'm wondering is, why do we use a
>direct store to memory in the first case, and the OUT instruction to
>write in the second case?

My guess is that the whole I/O section is mapped to Z-80 I/O, and that the
memory in the range that would be the I/O area in 128 mode is RAM only, where
-as $FF00 is hardwired into the memory map regardless of the mode.  Remember,
$FF00 is the shadow of the Configuration Register, and is required when the
I/O space is unavailable (due to it being switched out, or something), while
$D505 is the Mode configuration register, and would only be available as
an I/O port.

 
Jimbo
-------------------------------------

From: tratclif@oucsace.cs.ohiou.edu (Tracy Ratcliff)


Fuzzy Fox <fox@netcom.com> wrote:

>Here's my question, stated more clearly:  We all know that the program
>is trying to write $3E into $FF00, and $B1 into $D505, in order to
>accomplish the switchover.  What I'm wondering is, why do we use a
>direct store to memory in the first case, and the OUT instruction to
>write in the second case?


I'm not a z80 hardware guru, but I've seen this a couple of times:  The
z80 in the 128 is wired in so that an OUT instruction will write _only_
to the I/O device, while a LD will write to the I/O device _and_ to the
RAM location underneath at the same address.  You want to avoid the 
latter since it may trash any program sitting below the I/O space.

>Since the Z80 is sitting on the 8502 bus, it seems that all of its
>accesses of that bus (i.e. memory-mapped I/O) should work exactly the
>same way.  So the above code could be written as:

>       LD A,$3E
>       LD ($FF00),A
>       LD A,$B1
>       LD ($D505),A

>Since most programmers don't try to actively make things more difficult
>for themselves, I figure there is probably a good reason for the OUT
>instruction, but I can't see it.  And also, is the reverse true?  Could
>the first byte have been stored as 'OUT ($FF00),$3E' (using registers as
>appropriate, of course)?

At first thought, yes; at second thought, maybe not.  $ff00 is a "shadow
register", anything written there is also written to $d500 and vice versa.
An OUT command might not actually write to anything since $ff00 isn't
really an I/O device.

Tracy



  3.4  Processor Switching


From: Tracy Ratcliff <tratclif@oucsace.cs.ohiou.edu>
Subject:  Re: 8502 - Z80B

In article <36nm7v$msp@geraldo.cc.utexas.edu> you write:
>
>The following are questions I've been meaning to ask for some time:
>
>Is the Z80B accessible from C128 native Basic 7.0 mode?
Given a short ML routine, yes.
>
>Is the Z80B accessible through 8502 in any other way?
>(How does the CP/M bootstrap pass control from one chip to another?)

See below.
>
>In general, how does the 8502 / Z80B combo work together in CP/M?
>(The Z80B has to access the 6502 bus somehow...Is this why Z80B seems so 
>brain-dead on the 128?  By all rights it should be the much faster CPU.)
>
I believe that CP/M depends on CBM Kernal for some low-level I/O.

I've appended some stuff I found.  Reprinted without permission, etc.
Oh, the Power Assembler mentioned below has a z80 cross-assembler.
                         ------------------------

[A slightly edited version of pp 46-48 of the POWER ASSEMBLER 128
manual; a slightly different version appeared in TRANSACTOR Vol 7, Issue 3
Nov 86]

Bit 0 at $d505 (54533) controls the microprocessor mode. If it is 
turned on the the 8500 becomes active; if it is off then the z80
takes over.

You can't just poke it off (believe me).  A little housekeeping is
first in order.

Disable 8500 interrupts via SEI because you are going to switch to a 
memory configuration in which Kernal ROM is not visible.

To do this, store a $3e (62) at $ff00 (the configuration register).  This
leaves I/O RAM intact but switches everything else to RAM 0.

Managing two program counters

Your're still not quite ready.  The z80 PC register holds $ffed after 128
initialization.  There is a NOP ($00) there.  The first actual z80 
command goes at $ffee.  If you look through the monitor you will see a
$cf there.  This is a RST 8 opcode byte which will cause the z80 to jump
(ReSTart) to its own ROM routine at 0008.  You do not want this.  After moving
some 8500 code into place at $3000, the z80 would return control to the
8500.  The 8500 wakes up exactly where it left off after you switched to the
z80.  If you followed this switch with a NOP (let's not wake it up too fast)
and then a JMP $3000 (like the default code does) you would go into the 128's
boot CP/M routine.  This is pretty useless from a programming standpoint, so 
don't bother.  Instead, put you own z80 code at $ffee.

Before you do any z80 subroutine calls you should set its stack pointer 
register (SP) to point to some area that will not interfere with your
code or BASIC.

The last thing the z80 will have to do is to turn the 8500 back on. There 
are two ways to do this:

     ld a,$b1
     ld ($d505),a

This is inferior.  There is a bleed through condition in the z80 mode 
using this type of store.  A $b1 will also be written to underlying RAM.

Here is the proper way:

     ld bc,$d505
     ld a,$b1
     out (c),a

Bleed through does not occur using OUT storage and all i/o memory between
$d000 and $dfff can be written to.  In our BASIC coding sample the background
($d021) and border ($d020) are poked via the z80 OUT instruction.

Ordinarily you would have to bear in mind that the z80 might not
necessarily take off at $ffee the next time you activated it.  It, like the
8500, wakes up where it went to sleep.  The best procedure for switching
back and forth is to try to always put the microprocessors to sleep in the 
same spots.  Theses switches could be followed with jump commands.  Before
invoking them you could set the jump address for the other processor to
anywhere you like.  z80 ROM puts a RET ($c9) command after the 8500
switch allowing the z80 to CALL the 8500 from anywhere and return when
the 8500 switches back.  You can also put an RTS ($60) after the z80 
switch so that the 8500 can JSR the z80.

Now it just so happens that there are two routines high in RAM 0 through
which the two microprocessors can invoke each other.  The 8500 invokes
the z80 at $ffd0.  When the z80 returns control, the 8500 picks up at
$ffdb.  Leave the NOP ($ea).  You can take over at $ffdc (65500).

The z80 invokes the 8500 at $ffe0.  When the 8500 returns control, the
z80 picks up at $ffee -- and so on and so on.

Switcher

[Appended below] is a small Power Assembler source program called
"switcher-source" which handles the z80 stack, the user call, and
controls the "sleepy time" program counters for the two microprocessors
while making use of the RAM routines at $ffe0 and $ffd0.  Switcher 
thus allows you to easily execute hybrid programs and, as out
"invoke-z80.bas" example shows, even call the z80 from basic.

Switcher code sits at $3000, high in the 128's tape buffer.  The address of
the z80 code to be executed should be in the 8500's x (low byte) and a
(high byte) registers.  The BASIC program pokes some z80 code at $6000, then
after having Switcher get the z80 to execute it, continues in BASIC.  The 
z80 mode copies its ROM into RAM  at $8000.  Notice how easy it is to code 
move (4 instructions, 11 bytes).  The z80 then pokes the screen colors
just to show off.

10 sys 4000
20 ;"switcher-source"
30 ^
40 *=3000
50 .mem;  output to memory
60 ^
70 mmu             = $ff00;memory management register
80 ^
90 ;ram zero locations
100 ^
110 invoke128      =$ffe0; z80 code to switch
120 z80pc          =$ffee; z80 wakes up here
130 invokez80      =$ffd0; 8500 code to switch
140 c128pc         =$ffdc; 8500 wakes up here
150 safe'stack'top =$cfff; almost anywhere
160 ^
170 ;switcher code for hybrid processing
180 ^
190 ^   sei;        no interrupts
200 ^   sty mmu+1;  ram 0 config latch
210 ^
220 ;put z80 stack out of the way
230 ^
240 ^   ldy #$31;   ld sp opcode
250 ^   sty z80pc
260 ^   ldy <safe'stack'top
270 ^   sty z80pc+1
280 ^   ldy >safe'stack'top
290 ^   sty z80pc+2
300 ^
310 ;command to call z80 subroutine
320 ^
330 ^  ldy #$cd;    call (jsr) opcode
340 ^  sty z80pc+3
350 ^  stx z80pc+4; sys x parameter (low byte)
360 ^  sta z80pc+5; sys a parameter (high byte)
370 ^
380 ^
390 ;command to invoke the 8500 when done
400 ^
410 ^  lda #$c3;    jp (jmp) opcode
420 ^  sta z80pc+6
430 ^  lda <invoke128
440 ^  sta z80pc+7
450 ^  lda >invoke128
460 ^  sta z80pc+8
470 ^
480 ^  lda #$60;    8500's rts opcode
490 ^  sta c128pc;  for when it wakes up
500 ^
510 ;call user's z80 subroutine
520 ^
530 ^  jsr invokez80
540 ^
550 ;prepare to return to basic
560 ^
570 ^ lda #0
580 ^ sta mmu;      bank 15
590 ^ cli
600 ^ rts;          back to basic program

10 rem ***called "invoke-z80.bas"
20 rem ***this program will poke some z80
30 rem ***code into memory at $6000 and then
40 rem ***execute it via the switching
50 rem ***routine at 3000.
60 rem ***be sure to bload pivot-code
70 :
80 rem ***first put z80 code into memory
90 for x=0 to 21
100 read b
110 poke 24576+x,b
120 next x
130 sys 3000,96,0: rem call z80 at $6000
140 print "back alive and well!!!"
150 end
160 :
170 rem ***the z80 code to copy 4k rom to $8000 in ram 0***
180 data 33,0,0:     rem ld hl,0
190 data 17,0,128:   rem ld de,$8000
200 data 1,0,16:     rem ld bc,$1000
210 data 237,176:    rem ldir
220 rem ***z80 code to poke background and border color***
230 data 62,0:       rem ld a,0
240 data 1,32,208:   rem ld bc,$d020
250 data 237,121:    rem out (c),a
260 data 12:         rem inc c
270 data 237,121:    rem out (c),a
280 data 201:        rem ret
-----------------------------------

From: (George W. Taylor)
Subject: Re: 8502 - Z80B

The z80 is accessible from 128 mode only.  Control is passed by setting a 
bit in a register somewhere (I don't have a manual on hand, sorry).  If 
this bit is 1, then the current instruction is finished and the CPU is 
stopped (just like a DMA request).  Then the z80 takes over and continues 
exactly were it left off.  Normally this is the instruction after some 
boot up code in ROM.  There is a way to make it run your own programs.  I 
have some setup code in a book.  When the z80 is finished, it uses an OUT 
instruction to set the bit to 0 again, and then halts and the 8510 
continues where it left off.

You may think the z80 should be a lot faster, but really it is extremely 
inefficient.  You have to understand something about speed first.  MHz 
ratings are not everything.  MHz is the number of cycles per second.  
Each instruction takes so many cycles.  If you need a lot of cycles to do 
an instruction, it will take relatively more time.
The cycles of the 8502 are on average about 4 per instruction, and range 
from 2 to 7 (or even 9 with undocumented opcodes).
The z80 is very inefficient and starts at 3 and ranges up to about 24 
cycles.  So for example a 16 bit register add on the z80 takes 14 cycles 
while this is only 3 or 4 cycles on the 8502.
On average the 8502 can run the same task as well or better than a z80 at 
twice the speed.

The difference for the cycle times is due to pipelining.  This is a 
technique to reduce the cycles in a cpu, and is used in new RISC 
processors.  The 6502 has pipelining making it very efficient.  There are 
3 stages which are executed in parallel for each instruction.
Instruction decode, alu, and something else.  I need to look this stuff up.
But the 6502 is always fetching the next instruction at the same time as 
it's figuring out what to do with the current one, so when the current 
one is finished, it's part way through working on the next one.
Something like an assembly line.
For your last questions, I don't think there is any way to parallel 
process.  They would require the same bus at the same time which is not 
posible.
 
And I don't know why the manual is so inaccurate, but it always has been :)


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


  3.5  C128 CP/M Memory Layout

		I/O		BANK 0		   BANK 1

 FFFF	   -----------------+------------------------------------
			    |	CPU Control
 FF00-FF04 ====	MMU =========================	   Same as
			    |	BIOS		   Bank 0
		-	    |	BDOS
 EE00	   -----------------+------------------------------------
		-	    |					|
			    |	RAM 0		   RAM 1	|
 E000	   -----------------+ - - - - - - - - - - - - - - - - - |
	   |	I/O Area	If I/O Selected			|
	   |							|
 D000	   -----------------+ - - - - - - - - - - - - - - - - - |
			    |			   RAM 1	|
	        -	    |					|
 5400	   -----------------+-----------------	   TPA		|
	   |	VIC Colour					|
 5000	   -----------------+-----------------			|
			    |					|
		-	    |	Screen, Kbd			|
 1400	   -----------------+ - - - - - - - - - - - - - - - - -	|
	   |	VIC Colour	If I/O Selected			|
 1000	   +----------------+---------------- - - - - - - - - -	|
	   |	I/O Area    |	BIOS ROM			|
 0100	   |	(Except	    |	(RAM 0		----------------+
	   |	the MMU)    |	Unavailable)	   RAM 1	|
 0000	   +----------------+-----------------------------------+



Bank 0 always contains the Z80 BIOS ROM at memory area 0000-0FFF, disregarding
any memory confiruration settings.


Viel semmoinen havainto, ett yhteisen muistin avulla psee
esim. pankin 1 porttiosoitteista 0-FFF ksiksi pankin 0 muistiin.
yhteisen muistin avulla psee RAM pankin 0 muistipaikkoihin 0-FFF ksiksi,
joissa siis tavallisesti on se Z80:n piossi.

Osoitteissa 1000-13FF on kaikissa pankeissa vrimuisti, jos I/O-alue
on valittuna.
Muuten muistikonfiguraatiot ovat samat kuin 8502-tilassa, mutta D000-DFFF:ss
on RAMmia eik esimerkiksi ROMmia tai I/O:ta.
D500:ssa RAM ja MMU kilpailevat huomiosta, ja luettaessa tehdn
AND-toiminto muistin ja MMU-rekisterin sisllvn vlill.

0000-0FFF ohjautuu RAMmiin alueelle D000-DFFF (siis samassa
pankissa).  MMU ei vastaa 0500-05FF:n, mutta muut piirit ovat siell.


The Z80 "sees" the Colour RAM at 1000-13FF, whenever I/O is switched on, i.e.
if you use the 3E configuration (60 kB bank 0 RAM and 4 kB I/O).

Also, 5000-53FF is Colour Memory, but unlike the previous area, this one always
remains available.
D000-DFFF is the official C128 I/O area for IN and OUT instructions.
Port addresses D000-DFFF always give access to the I/O.

The rest works the same way as with LD instruction, i.e. access ROM or RAM.

I/O addresses for IN and OUT are 16 bits wide, even though all Z80 books
probably claim them 8 bits only.
Therefore, commands like  IN A,(C)  actually set the contents of BC register
pair on the address lines.  So does INIR, but B is also used as a counter.

So, reading, say 255 bytes from port F0 to 3000-30FF will actually read from
FFF0, FEF0, FDF0, etc.


Leikin vield kaiken pddtteeksi ultimax-tilallakin.  Tein 17 kellojaksoa
pitkdn silmukan ja laitoin videopiirin hakemaan tekstindytvn merkit
3000-3FFF:std.  tiedoksi: 312*63-25*43=18581=kellojaksojen mddrd tavallisella
tekstindytvlld on 17:lla jaollinen.  Harmistuksekseni kuviossa oli liev
vrin.  ja kun ajoi kskykoodin 2, kuvio rupesi oudosti (mutta snnllisesti)
vrhtelemddn.  Sama vaikutus oli Restoren tkkmisell.


        Marko


  3.6 CP/M Plus

 An image of the Commodore 128 CP/M Boot Disk is required in order to use
 the CP/M opereting mode.
 Alternatively, an advanced user can use dump of the CP/M RAM, saved after
 successfully booting CP/M.

 [Since the cost (license fee) of the CP/M disk only was about $3 (12 FMK),
 an original cannot be too much asked. Otherwise, you probably won't even want
 to use it...]


  4. SCREEN EMULATION AND VIC

	"standard SG Indy can blast 32 million pixels to screen memory in a
	second- enough to regenerate an entire 1280 by 1024 pixel screen 24
	times in a second" their ad claims.


    Screen Raster Line:
 
     Clock * Rfsh_per_sec * Screen Lines
   ----------------------------------------  MOD  Scren Lines = Current Line
                Cycles_per_sec


    VIC-II Multicolor Modes

	Code	Bitmap	  Extended	MultiC Text
	00	BG 0	    BG 0	 BG 0
	01	UpperN	    BG 1	 BG 1
	10	LowerN	    BG 2	 BG 2
	11	ColorN	    BG 3	 Color (3 bit)



    Colour Memory

 The colour memory is 1K x 8 bit or, on new machines 2K x 8 bit Static RAM.
 Only the low 4 bits are used. Officially, the rest 4 bits are 'not connected'
 and thus 'undefined'.
 On a real C64 or C128 one will random values for the top 4 bits every time
 he reads them. Valid data is only available by ANDing the results with 15.

 Still, some machines don't have the high 4 bits set to 0, some are even all
 1s. Some people have expanded their machines to have 8 bits of RAM there for
 various reasons though....  :)


 This is how different emulators handle:  POKE 55296,255

   PC/Unix
	X64				255

   PC
	PC64  v1.18			 15
	PC64  2.0b for Windows		255
	C64S  1.1b			255
	Win64 v.01b			255

  Amiga
	Frodo 1.5			top 4 bits vary randomly
	A64 3.0				top 4 bits vary randomly




  VDC -- the C128 80 col Display Controller


	VDC 8563  Register Definitions

 
 Reg     7    6    5    4    3    2    1    0     Description              Notes
------ ---- ---- ---- ---- ---- ---- ---- ----   ------------------------ -----
     0	HzT7 HzT6 HzT5 HzT4 HzT3 HzT2 HzT1 HzT0   Horizontal Total	     1
     1	HzD7 HzD6 HzD5 HzD4 HzD3 HzD2 HzD1 HzD0   Horizontal Displayed       1
     2	HzS7 HzS6 HzS5 HzS4 HzS3 HzS2 HzS2 HzS0   Horizontal Sync Position   1
     3	VSW3 VSW2 VSW1 VSW0 HSW3 HSW2 HSW1 HSW0   Vert/Horiz. Sync Width     2
     4	VeT7 VeT6 VeT5 VeT4 VeT3 VeT2 VeT1 VeT0   Vertical Total	     3
     5	.... .... .... VeA4 VeA3 VeA2 VeA1 VeA0   Vertical Total Fine Adju   3
     6	VeD7 VeD6 VeD5 VeD4 VeD3 VeD2 VeD1 VeD0   Vertical Displayed	     3
     7	VeS7 VeS6 VeS5 VeS4 VeS3 VeS2 VeS1 VeS0   Vertical Sync Position     2
     8	.... .... .... .... .... .... Ilc1 Ilc0   Interlace Mode             4
     9	.... .... .... CTV4 CTV3 CTV2 CTV1 CTV0   Character Total Vertical   5
0a  10	.... CrM1 CrM0 Css4 Css3 Css2 Css1 Css0   Cursor Mode/ Start Scan    6
0b  11	.... .... .... Ces4 Ces3 Ces2 Ces1 Ces0   Cursor End Scan    	     6
0c  12	Ds15 Ds14 Ds13 Ds12 Ds11 Ds10 Ds09 Ds08   Display Start Adrs (Hi)    7
0d  13	Ds07 Ds06 Ds05 Ds04 Ds03 Ds02 Ds01 Ds00   Display Start Adrs (Lo)    7
0e  14	Cp15 Cp14 Cp13 Cp12 Cp11 Cp10 Cp09 Cp08   Cursor Position (Hi)	     7
0f  15	Cp07 Cp06 Cp05 Cp04 Cp03 Cp02 Cp01 Cp00   Cursor Position (Lo)	     7
10  16	LpV7 LpV6 LpV5 LpV4 LpV3 LpV2 LpV1 LpV0   Light Pen Vertical	     8
11  17	LpH7 LpH6 LpH5 LpH4 LpH3 LpH2 LpH1 LpH0   Light Pen Horizontal	     8
12  18	Ua15 Ua14 Ua13 Ua12 Ua11 Ua10 Ua09 Ua08   Update Address (Hi)	     9
13  19	Ua07 Ua06 Ua05 Ua04 Ua03 Ua02 Ua01 Ua00   Update Address (Lo)	     9
14  20	At15 At14 At13 At12 At11 At10 At09 At08   Attribute Start Adrs (Hi)  7
15  21	At07 At06 At05 At04 At03 At02 At01 At00   Attribute Start Adrs (Lo)  7
16  22	HcP3 HcP2 HcP1 HcP0 IcS3 IcS2 IcS1 IcS0   Hz Chr Pxl Ttl/IChar Spc   A
17  23	.... .... .... VcP4 VcP3 VcP2 VcP1 VcP0   Vert. Character Pxl Spc    5
18  24	BlkM RvsS Vss5 Vss4 Vss3 Vss2 Vss1 Vss0   Block/Rvs Scr/V. Scroll 9,B,C
19  25	Text Atri Semi Dble Hss3 Hss2 Hss1 Hss0   Diff. Mode Sw/H. Scroll  D,E
1a  26	Fgd3 Fgd2 Fgd1 Fgd0 Bgd3 Bgd2 Bgd1 Bgd0   ForeGround/BackGround Col  F
1b  27	Rin7 Rin6 Rin5 Rin4 Rin3 Rin2 Rin1 Rin0   Row/Adrs. Increment	     G
1c  28	CSa2 CSa1 CSa0 RamT .... .... .... ....   Character Set Address/Ram H,I
1d  29	.... .... .... UdL4 UdL3 UdL2 UdL1 UdL0   Underline Scan Line	     6
1e  30	WdC7 WdC6 WdC5 WdC4 WdC3 WdC2 WdC1 WdC0   Word Count (-1)	     9
1f  31	Dta7 Dta6 Dta5 Dta4 Dta3 Dta2 Dta1 Dta0   Data			     9
20  32	BlkF BlkE BlkD BlkC BlkB BlkA Blk9 Blk8   Block Copy Source (hi)     9
21  33	Blk7 Blk6 Blk5 Blk4 Blk3 Blk2 Blk1 Blk0   Block Copy Source (lo)     9
22  34	DeB7 DeB6 DeB5 DeB4 DeB3 DeB2 DeB1 DeB0   Display Enable Begin	     J
23  35	DeE7 DeE6 DeE5 DeE4 DeE3 DeE2 DeE1 DeE0   Display Enable End	     J
24  36	.... .... .... .... Drm3 Drm2 Drm1 Drm0   DRAM Refresh Rate	     K




   VDC Attribute Memory

	80	Character Set	(1 = Lowercase)
	40	Reversed
	20	Underlined
	10	Flashing
	08	RGB Red
	04	RGB Green
	02	RGB Blue
	01	RGB Intensity

 These attributes are fetched from Char Colour at location F1 in RAM whenever
 a character is printed on the VDC screen.


	Colour Codes

	Code	RGBI	Colour

	  0	0000	Black
	  1	1111	White
	  2	1000	Dark Red
	  3	0111	Light Cyan
	  4	1011	Light Purple
	  5	0100	Green
	  6	0010	Blue
	  7	1101	Yellow
	  8	1010	Dark Purple  (VIC: Orange)
	  9 	1100	Brown
	 10	1001	Light Red
	 11	0110	Dark Cyan  (VIC: Dark Gray)
	 12	0001	Medium Gray
	 13	0101	Light Green
	 14	0011	Light Blue
	 15	1110	Light Gray


 Attribute memory is enabled by bit 6 in register 25 ($19). Disabling it
 makes VDC to use the Foreground/Background register (26) instead.



  C128 VDC RAM (80 column display)


From: Raymond Carlsen <rrcc@u.washington.edu>
Subject: Re: W: 8564 RAM swap instructions
Date: Wed, 27 Sep 1995 20:50:02 -0700

> The subject says it all. How do you do this 16k to 64k swap?

     I assume you mean the video RAM upgrade for the C-128. If you're 
good with a de-soldering iron, it just involves removing two chips from 
the board and installing replacements. The original chips are 4416 DRAM 
at board locations U23 and U25 inside the metal can, between the VIC and 
RGB chips. The replacements are 4464. The numbers on the chips may vary 
with manufacturers, but the originals are 4 bit wide 16K... two of them 
make 16K by 8 bits. The upgrade to two 4 bit wide 64K chips give a 
total of 64K by 8 for the flat 128. The 128D was built with 64K of VRAM 
already installed. 
     I always install sockets anytime I replace chips in a PC board. 
Removing the old chips is the worst part of the job. Probably the easiest 
way is to cut all of the pins on the old chip, then remove them one at a 
time with a regular iron. As a tech, I hate to destroy anything that 
still works. I use a desoldering iron to free each pin, then remove the 
chip intact. If the new chips don't work for any reason, I can cross 
check my work by reinstalling the old ones. Sockets mean never having to 
solder again. It's important to orient the new chips in the board 
correctly. One end of the chip will have a notch and the outline on the 
board will match. 
     Unless you have software that takes advantage of the extra video RAM
you will not see any difference in the performance of your computer. I 
think Maverick uses that RAM space to speed up copying files. It's useful 
for improved bitmapped graphics. It is only good for the 80 column 
screen... the 40 column VIC doesn't access it. To verify C-128 VRAM as 
either 16K or 64K, run this little program:
POKE DEC("D600"),28:POKE DEC("D601"),63:SYS DEC("FF62"):SCNCLR  <RETURN>
If the screen shows the READY prompt and looks normal, the 128 has 64K 
of VRAM installed. If it only has 16K (stock 128 without upgrade), the 
screen fills up with zeros. Hit RUN/STOP-RESTORE to clear it. 
     At one time, some company was selling a piggyback board with the RAM 
installed. It needed no soldering as the on-board 4116s were bypassed. All 
that was necessary was to remove the 80 Column RGB (8563, also known as 
the VDC) chip from its' socket, install the piggyback board and plug the 
RGB chip into the piggyback. I haven't seen that board advertised for 
some time. 
     Chips are available from Jameco Electronics @ 1-800-831-4242. Order 
part #41582 (41464-12), or 41574 (41464-10), or 41611 (41464-80). They 
cost less than 3 bucks each. Jameco also has other replacement chips for 
Commodore computers. 


          Ray Carlsen  Univ. of Washington, Seattle

############################################################


Subject: Re: How to detect 64k on the VDC of the 128?


Its been YEARS since I did any programming of that sort.  If memory serves 
me correctly, all you have to do is fill up the RAM 16k at a time with 
different numbers.  BUT DON'T OVERWRITE CHARACTER RAM OR ELSE!!!  Let me 
explain:

The first 16k would be filled with, say $FF   (Remember don't overwrite
                                               the character set!!).
The next 16k with $9F
The next 16k with $1F
The final 16k with $00

   Now check the first 16k of memory.  If you have 64k of VRAM, then it 
will contain $FF just like it did before.  If not, it will contain $00.
Come to think of it, since you are only testing for 16k or 64k (and 
nothing in between) you probably need only test the first 16k and the last 
16k of address space.  You can ignore the middle two.

   The reason this works is if you have 16k the computer still sees a full 
64k but when you go above the 16k address it "wraps around" to the start 
(it ignores the two high bits of your 16-bit address).  So if you put 
something in memory at address 17k, it would show up at both 17k and 1k 
(and also at 33k and at 49k).


   If I am wrong about this, and the C128 memory works the other way, then 
try this method:

1. Get the contents of some address above 16k.  Say $CFFF or something.
2. POKE in a different number.  The easiest way to do this is to use 
either 255 ($FF) or 0 ($00).  Just make sure that this number DOES NOT 
EQUAL the number that was there previously.
3. Get the contents of the address again.  If it contains the nuber you 
just put into it (step 2) then there is RAM there.  If not, then it is ROM 
or something.

NOTE:  TRY BOTH METHODS.  This second method will give false results if 
C128 memory is wired up the way I explained at the begining of all this.
  I have programmed many different computers and its easy to be confused 
between peculiarities of the Atari, Commodore, ect...  But I know FOR SURE 
that one of these methods will work.



Subject: RE: Detecting VDC

This program works for detecting VDC in your 128:

 1 rem fred's nifty program to determine size of 8563 dram
 5 w=dec("cdcc"):r=dec("cdda")
 10 bank15: ad=dec("d600"): da=ad+1 :rem setup ml
 20 pokead,28: s=peek(da): pokeda,63 :rem select 64k
 30 i=16896: sysw,i/256,18:sysw,iand255,19:sysw,85,31 :rem write $55
 40 i=16896: sysw,i/256,18:sysw,iand255,19:sysr,,31:rregc1 :rem read here
 50 i=17152: sysw,i/256,18:sysw,iand255,19:sysr,,31:rregc2 :rem and here
 60 i=16896: sysw,i/256,18:sysw,iand255,19:sysw,170,31     :rem write $aa
 70 i=16896: sysw,i/256,18:sysw,iand255,19:sysr,,31:rregc3 :rem read here
 80 i=17152: sysw,i/256,18:sysw,iand255,19:sysr,,31:rregc4 :rem and here
 90 pokead,28: pokeda,s:sysdec("ff62") :rem restore 16/64k
 95 print chr$(14)chr$(147)
 100 if c1=c2 and c3=c4 then print "16K": else print"64K"  :rem did it
echo? 
 110 end


There is a much shorter option:

POKE DEC("D600"),28:POKE DEC("D601"),63:SYS DEC("FF62"):SCNCLR

If you have 16k the screen will fill with zeros; 64k will give you a 
ready prompt.



From: Bruce McFarling <brmcf@utkux.utk.edu>
Subject: Re: 128D VDC size
Date: Mon, 23 Oct 1995 12:22:52 -0400


> Me got a European 128D <<german, as it happens>> and I was wondering if 
> theres any easy way <<a POKE or something>> to find out if its got the 
> 16K or 64K Vid RAM, as Ive heard that some D's do, and some D's dont! :-)

	Yeah, that was answered.  It seems that you use the access 
registers to write a value somewhere in the first 16K.  Then you write a 
different value somewhere exactly 16K, 32K, or 48K higher up.  Now 
read the higher value.  If you get it back you're getting addressed above 
16K.  Ah, but is it just the same 16K wrapped around?  Read the original 
(in the lower 16K of the address space).  If you got back what you put 
there, you've got 64K.
	The idea here was that (a) if the 16K wrapped around in the 64K 
address space, it works, and (b) if there is simply nothing there, it stil 
works.  However, if someone with the info would say whether its (a) or 
(b), you could skip a step:
	(a) If we know a 16K RAM always wraps around to show up four 
times in the 64K RAM space, simply read a value in the lower 16K, XOR it 
with 0, store that in the corresponding place exactly 16K, 32K, or 48K 
higher, then XOR that value with the value now in the original (low) 
location.  True (all bits 1) implies the low value stayed the same, hence 
there is a 64K, false (all bits 0) implies 16K. *Assuming* the 16K is 
mirrored.
	(b) If we know that with a 16K RAM, addresses above 16K return a 
constant, read a value above 16K, XOR it with 0, store it, then XOR that 
value with what you read from the address.  Same True and False, 
*Assuming* that with 16K, addresses above 16K do *not* mirror.
	(c) Actually, if you try both, and they both say True, you know 
you have 64K, but you don't know which one works.  If you try both, and 
only one says False, you know you have 16K, and you know which one 
works.  So if someone tries this on an unexpanded flat 128, we will know 
which one works.

	Oops, seems I have assigned myself an experiment. :)  Results 
next week.

Bruce McFarling, Knoxville
brmcf@utkux.utk.edu



I used the testprogram in Maverick to find out the size of videoram!

From: Pontus Berg <Pontus.Berg@p71.anet.canit.se>
/Pontus Berg, Bacchus@FairLight.COM






  5. Sound, SID

  Only the random number generator is implemented on VICE C=64/128 emulator.


From: hermit@cats.UCSC.EDU (William R. Ward)

 The SID chip has 3 voices which can do four waveforms: square, triangle,
 sine, and white noise.  You can manipulate the attack, decay, sustain, and
 release values (ADSR) for each voice for 16 possible values of each. There
 is a volume control that controls the loudness (16 levels) for all three
 voices.  In addition there are high-pass, low-pass, and band-pass filters
 which can be configured to apply to all three voices together. There is even
 an audio input line which is rarely used; it will be mixed in with the output
 from the SID but is only affected by the filters.

 If you do an internal hardware hack, or purchase a SID Symphony cartridge,
 you can add a second SID chip to your C64 or C128 that is supported by some
 common music software, giving you 6 voices and stereo sound.





  6. I/O Ports


  6.1 The CIAs

	      +-------+-------+-------+-------+-------+-------+-------+-------+
    CIA #1    | 	Write Keyboard Column Values for Keyboard Scan        |
 Data Port A  +-------+-------+-------+-------+-------+-------+-------+-------+
 DC00  56320  |  Paddles A/B  |       | Fire  | Right | Left  | Down  |  Up   |
	      +-------+-------+-------+-------+-------+-------+-------+-------+

	      +-------+-------+-------+-------+-------+-------+-------+-------+
   CIA #1     | 	 Read Keyboard Row Values for Keyboard Scan	      |
 Data Port B  +-------+-------+-------+-------+-------+-------+-------+-------+
 DC01  56321  |Timer B|Timer A|       | Fire  | Right | Left  | Down  |  Up   |
	      +-------+-------+-------+-------+-------+-------+-------+-------+


   CIA #2     +-------+-------+-------+-------+-------+-------+-------+-------+
 Data Port A  | SDA In| CLK In|SDA out|CLK Out|ATN out| RS232 |    VIC Bank   |
 DD00  56576  +-------+-------+-------+-------+-------+-------+-------+-------+

	      +-------+-------+-------+-------+-------+-------+-------+-------+
   CIA #2     | 		User Port Read/Write Values		      |
 Data Port B  +-------+-------+-------+-------+-------+-------+-------+-------+
 DD01  56577  |  DSR  |  CTS  |   CD  |       |   RI  |  DTR  |  RTS  |  RxD  |
	      +-------+-------+-------+-------+-------+-------+-------+-------+


  6.2 Tape Unit

The operation of tape unit is based on four signal lines: READ, WRITE, SENSE
and MOTOR.

The active low SENSE line is an input to P4 of the 6510 onboard Peripheral Port
It is used to detect whether any of the operation buttons (PLAY, Fast Forward
or REWIND) has been pressed, giving the needed acknowledge to control the MOTOR
output.

The two data lines are used to READ and WRITE data to the cassette deck.
The WRITE line is connected to P3 of the CPU onboard I/O port, and the READ
line (normally pulled high) is connected to the FLAG input of 6526 CIA#1.

On the tape deck itself, the WRITE signal is amplified and sharpened with a few
inverters before it is fed to the write head. Similarly, when reading, the
picked up transitions are boosted by an op-amp and then inverted twice. Thus,
should you get programs recorded in the inverted phase (i.e. trough radio
transmission) it's easy to install a switch to drop off the last inverter on
the read line.

To provide for the greatest reliability, the CBM machines employ extensive
error checking in the use of cassette tape.
It operates on two levels:

First, data is split into chunks of 8 bytes. These are added together and the
low byte of the result - the checksum - is written to tape right after them.
When the tape is read, the eight bytes are added together and the result is
compared with the checksum digit. If they are different, then an error has
occurred.

The second level of error checking involves recording each block of 192 bytes
twice (or the whole program twice for binary files). Any errors that were
detected and flagged by the checksum digit can be corrected with the second
pass data. The two blocks are also verified against each other to detect those
few errors not found by the checksum.

Eack byte of data is recorded as a series of square wave pulses, consisting of
the 8 data bits, one parity bit and a byte marker. The mark:space ratio for
these pulses is 1:1.

There are three different frequencies used:
	Long pulse	1.488 kHz
	Medium pulse	1.953 kHz
	Short pulse	2.840 kHz

'0' is defined as one short pulse followed by one medium pulse. '1' is defined
as one medium pulse followed by one short pulse. Both of these values have the
same total length of 864 us.

A byte marker indicates the start of a new byte and consists of one long pulse
followed by one medium pulse. The gap between the first and the second pass
data is indicated by one long pulse and at least 50 short pulses.

At the start of recording, a 10 second leader is written consisting of short
pulses. This enables the operating system to syncronize the read timing to the
tape timing, enabling a wide variation of tape speeds to be read successfully.
The two second inter-record gap is also written as a series of short pulses.

The syncronization of tape and read timing allows for variations in tape motor
speed of up to 20 percent. Unfortunately, the DMA (Direct Memory Access)
operations required by the VIC-II (or VIC-IIe) chip to generate the 40 column
screen display can occasionally push the timing beyond its limits. To overcome
this, the VIC chip is disabled and the screen blanked during cassette operations.

Immediately after the leader, a 192 byte file header is written. This contains
details of the file type, its filename as well as both the start and end address
(On an ASCII file, these point to the start and ent of the cassette buffer.)
An additional header can be written at the end of the file indicating that
End of Tape has been reached.


  6.2.1 Tape File Header Format

	Byte	Contents

	0	File Type Flag
		 1,3 = Program or RAM Image
		  4  = Data
		  5  = End Of Tape

	1-2	Start Address
	3-4	End Address
	5-21	Filename

 Note: At least Simon's Basic supports filanames longer than 16 chars.


  6.2.2 Tape Turbo

From: boose@misa.extern.fh-hannover.de (Andreas Boose)
Subject: Re: Datassette maximum speed???

ai641@torfree.net (Gary Chiasson) writes:

>I have a 1530 Datassette (tape recorder) for the commodore 64.
>I also have a program called "Turbo Tape" that speeds up the saving / loading
>of data by compressing it.  Is there another software program that is
>even faster?

Yes, some cartridge's turbo loader/saver are faster, but not so reliable.
Turbo Tape encodes 1 and 0 into a simple "x-x-x--x--x" stream without
framing and just one EOR checksum. An "x" means a polarity change of the
magnetic flux at the r/w head. The data is encoded in the time the next
flux change appears (FM). The implementation I examined (the original one,
written by Stephan Senz, Freiburg, Germany) uses 2*~110=~220 microseconds
between two changes as "0" and 2*~167=~334 microseconds as "1".

Faster programs use the same routines, but the loop before the STA$01 is
decreased. This is very risky as the attenuation of the tape and datasette
increases dramatically on higher frequencies. You can adjust Turbo Tape to  
nearly any speed you want, just change the values of the X-register in the  
$c4b1 write subroutine and the corresponding $dd06/7 timer value (normally  
266 microseconds) in the $c5f0 read subroutine.

If you choose very small values successfully loading 50KB Elite within 3
seconds, you can be sure that you bought the best datasette compatible
cassette tape of the world. ;-)

>Is there a program that I can use to save a program on disk (over 160 blocks)
>to the Datassette on tape?

Yes, 64'er magazine has published a follow-up to their successful
Turbo Tape called "61k-turbo". This speeder is Turbo Tape compatible and
allows to load/save to/from ~$0700-$ffff RAM. (Don't ask me why they
called it "61k"...)

MfG Andreas


  6.2.3 Tape with Disk Turbo

From: schonef@asterix.uni-muenster.de (Marc Schonefeld)
Subject: Tape Drive and Dolphin Dos
Date: 18 Sep 1995 23:28:13 GMT

Tape Access and Dolphin Dos is possible , all you have to do 
is to rip the tape routines , move them to the end of turbotape
then relocate the whole bunch to $FC00 , write some bank switching 
routines as access point in the $CF00 area ... and then enjoy tape
access with dolphin dos or any other funny dos .....

Does anyone know if and then when ESCOM will start selling C64 in 
Germany again ? 




From: Pontus Berg <PBG@HK.Mobitel.Telia.SE>
Subject: Re: Tape Drive Power!
Date: 20 Sep 1995 08:20:15 GMT

Jan.Lund.Thomsen@p11.f128.n238.z2.fidonet.org wrote:

>> Also, JiffyDOS does not work with the cassette port

>Dolphin Dos also disabled the tape deck. AFAIR they used the memory
>(tape-buffer, etc.) for the fastloader, and as a reviewer once said:

>"If you have a 25x floppyloader, why would you want to use your tapedeck?"

Well I had SEVERAL reasons to revert from DiskDemon to Normal Kernal V3.
One of the troubles I had (but I know you didn't Jan) was that I couldn't run
 Expert 4.1 with the Demon enabled! 

Only a few weeks ago I found the error! The Expertmonitor uses an init from
the tape specific routines that is just not there on either Jiffy (correct me
if I'm wrong here) and not on DiskDemon either. I don't know if I might run
into troubles here but I just removed the JSR (lacking ANY room to but a copy
of the routine some place in the monitor!) and it did work great!


>Anyway, you could disable it with a flick of a button and load all your old
>tape games.

Right, but using an Expert without Turbo saving a 250 block file ($0800-$fffa)
is not something I recommend unless you have LOTS of spare time! ;-)


)  o/      PBG@HK.Mobitel.Telia.SE   or   Bacchus@FairLight.COM	 (



From: Rick <slick_rk@xmission.com>
Subject: Re: Tape Drive Power!
Date: Thu, 21 Sep 1995 12:35:21 -0600

On Wed, 13 Sep 1995, Chris Gioconda wrote:

> 
> 
> >  EE>      My c128d, for some odd as hell
> >  EE> reason, is no longer granting power
> >  EE> to the tape drive.  I checked each pin
> >  EE> and found pin2 (+5v) to be giving
> > Check the fuse, the cassette port on the 128D has its own fuse.
> 
> Also, JiffyDOS does not work with the cassette port...


Actually with JiffyDos the cassette port still has power. But the JiffyDos 
chip takes the input address for some of it's functions. Which is why I 
had a copy of the kernal from a stock c64 put on the flip side of my 
chip. SO I can with a flip of a switch go from JiffyDos to a stock c64. 
Hence all of the programs I find that JIffDos doesn't like I can still 
run. Plus still access my tapes.

Rick Kelley		slick_rk@xmission.com


  7. KEYBOARD

  C64/C128 Keyboard Layout

 Below is shown the keyboard layout of a real VIC-20 and C64 computers.
 They both use the same keyboard mechanism, only wiring on the motherboeard
 differs. The keyboard mechanism is interchangeable between VIC-20 and the C64.
 However, on the main circuit board (motherboard), the VIC-20 has all the lines
 connected to the VIA chip in order, whereas C64 has Column3 and Column7
 swapped. That's why the C64 gives different keyboard matrix. It also affects
 to the keycodes returned.

 Since C128 has also nationalized mode, also the C64 mode uses
 that layout instead of the standard. There are also programs which
 remap the C64 keyboard and character set.

 The C16 keyboard also resembles this, but both the keyboard matrix and some
 keycaps are different.


	VIC-20 / C64 Standard:

  |  <-  1!  2"  3#  4$  5%  6&  7'  8(  9)  0   +   -  GBP HOME DEL |  | F1 |
  | CTRL   q   w   e   r   t   y   u   i   o   p   @   *  ^~ RESTORE |  | F3 |
 | RUN LOCK a   s   d   f   g   h   j   k   l   :[  ;]  =   RETURN  |   | F5 |
 | C=  SHIFT  z   x   c   v   b   n   m   ,<  .>  /?  SHIFT DWN RGT |   | F7 |
 -------------|_______________SPACE_______________|------------------

	'~' is 'pi'


	C128 Standard:

 Esc  Tab  Alt  Caps    Help LF  40/80 NoScr    Up  Dwn Lft Rgt    F1 F3 F5 F7

 |  <-  1!  2"  3#  4$  5%  6&  7'  8(  9)  0   +   -  GBP HOME DEL | |7 8 9 +|
 | CTRL   q   w   e   r   t   y   u   i   o   p   @   *  ^~ RESTORE | |4 5 6 -|
 | RUN LOCK a   s   d   f   g   h   j   k   l   :[  ;]  =   RETURN  | |1 2 3  |
 | C=  SHIFT  z   x   c   v   b   n   m   ,<  .>  /?  SHIFT DWN RGT | | 0  . E|
 ---------------|_______________SPACE_______________|---------------- ---------

	'~' is 'pi'


	C128 Swe/Fin:

 Esc  Tab  Alt  Asc/CC   Help LF  40/80 NoScr    Up  Dwn Lft Rgt    F1 F3 F5 F7

 |  <-  1!  2"  3#  4$  5%  6&  7'  8(  9)  0   -   =   :* HOME DEL | |7 8 9 +|
 | CTRL   q   w   e   r   t   y   u   i   o   p   ]   @  ^~ RESTORE | |4 5 6 -|
 | RUN LOCK a   s   d   f   g   h   j   k   l   \   [   ;+  RETURN  | |1 2 3  |
 | C=  SHIFT  z   x   c   v   b   n   m   ,<  .>  /?  SHIFT DWN RGT | | 0  . E|
 ---------------|_______________SPACE_______________|---------------- ---------

	'~' is 'pi'
	']' is 'aa'	(a-ring)
	'[' is 'ae'	(a-dieresis)
	'\' is 'oe'	(o-dieresis)	(GBP on the standard C64/128)



 VIC-20 Keyboard Matrix

 9120	9121:
  fe	RunStop	q	CBM	Space	2	Control	Lft_arr	1
  fd	Shift_L	e	s	z	4	a	w	3
  fb	x	t	f	c	6	d	r	5
  f7	v	u	h	b	8	g	y	7
  ef	n	o	k	m	0	j	i	9
  df	,	@	:	.	-	l	p	+
  bf	/	Up_arr	=	Shift_R	Home	;	*	GBP	
  7f	Down	F5	F3	F1	F7	Right	Return	Del

  Note: VIC-20 scans the keyboard just the opposite way compared to C64,
   so it writes the column to 9121 and reads 9120.


 C64 Keyboard Matrix

 dc00	dc01:
  fe	Down	F5	F3	F1	F7	Right	Return	Del
  fd	Shift_L	e	s	z	4	a	w	3
  fb	x	t	f	c	6	d	r	5
  f7	v	u	h	b	8	g	y	7
  ef	n	o	k	m	0	j	i	9
  df	,	@	:	.	-	l	p	+
  bf	/	Up_arr	=	Shift_R	Home	;	*	GBP	
  7f	RunStop	q	CBM	Space	2	Control	Lft_arr	1

 C128 Keyboard Extension

 d02f	dc01:
  fe	KP_1	KP_7	KP_4	KP_2	Tab	KP_5	KP_8	Help
  fd	KP_3	KP_9	KP_6	KP_Entr	LineFd KP_Minus	KP_Plus	Esc 
  fb  NoScroll	Right	Left	Down	Up	KP_Dot	KP_0	Alt


 Values	128	64	32	16	8	4	2	1
	 7F	BF	DF	EF	F7	FB	FD	FE

 Note:  [Control], [Shift_L], [Shift_R] and [CBM] do not give any keycode.



	Commodore 128 keycodes

Keycode	Unshift	Shift			Keycode	Unshift	Shift

Row 0					Row 6
  0	Del	Inst			 48	 (sterling)
  1	Return				 49	*	
  2	Right	Left			 50	;	]
  3	F7	F8			 51	Home	Clear
  4	F1	F2			 52	
  5	F3	F4			 53	=	
  6	F5	F6			 54	UpArrow	Pi
  7	Down	Up			 55	/	?

Row 1					Row 7
  8	3	#			 56	1	!
  9	w	W			 57	LeftArrow
 10	a	A			 58	
 11	4	$			 59	2	"
 12	z	Z			 60	Space
 13	s	S			 61	
 14	e	E			 62	q	Q
 15					 63	Stop	Run

Row 2					Row K0
 16	5	%			 64	Help  1)
 17	r	R			 65	KP_8
 18	d	D			 66	KP_5
 19	6	&			 67	Tab
 20	c	C			 68	KP_2
 21	f	F			 69	KP_4
 22	t	T			 70	KP_7
 23	x	X			 71	KP_1

Row 3					Row K1
 24	7	/			 72	Esc
 25	y	Y			 73	KP_Plus
 26	g	G			 74	KP_Minus
 27	8	(			 75	Linefeed
 28	b	B			 76	KP_Enter
 29	h	H			 77	KP_6
 30	u	U			 78	KP_9
 31	v	V			 79	KP_3

Row 4					Row K2
 32	9	)			 80	
 33	i	I			 81	KP_0
 34	j	J			 82	KP_Dot
 35	0	=			 83	Up
 36	m	M			 84	Down
 37	k	K			 85	Left
 38	o	O			 86	Right
 39	n	N			 87	NoScroll

Row 5					 88	No Key  1)
 40	+	
 41	p	P
 42	l	L
 43	-	
 44	.	>
 45	:	[
 46	@	
 47	,	<


 Notes:
	1) On the C64 keycode 64 is NO KEY instead.


 The following keys do not return any keycode:

 (15)	Shift_L + ShiftLock
 (52)	Shift_R
 (58)	Control
 (61)	C=
 (-)	Restore
 (80)	Alt
 (-)	CapsLock/CC
 (-)	40/80



  The keyboard emulation on X64

 The CBM needs to read the keypress at least twice before it can do anything:
 first, it checks if ANY key is down and then polls for each line if needed.

 To make this easier there is now keypress queue to keep key images in the
 matrix until the program has a chance to read them. But since X11 covers some
 of the needed information, we don't know how many keys were pressed
 simultaneously -- unless they begin to autorepeat. 

 The worst thing is that some keyboards don't have a clue when a key is
 released, so we have to guess it. And special keys like shift are silent too.

 There are no shadow keys emulated yet.


 Below is a simple program to draw the keyboard matrix on screen.
 It can be found in binary as "Test/matrix1300"

 1300           SEI
 1301   i1301   LDA #$13	; home
 1303           JSR $FFD2
 1306           LDY #$00
 1308   i1308   LDA $1350,Y	; row mask
 130B           LDX #$08
 130D           STA $DC00
 1310           BIT $DC00
 1313           BNE $1315
 1315   i1315   LDA $DC01	; handle one row
 1318   i1318   PHA		; handle one key
 1319           AND #$80
 131B           EOR #$AE
 131D           JSR $FFD2
 1320           PLA
 1321           ASL
 1322           DEX
 1323           BNE $1318
 1325           LDA #$0D
 1327           JSR $FFD2
 132A           INY

 132B           CPY #$08
 132D           BCC $1308	; next row
 132F           JMP $1301	; scan again

 ; row masks

 1350   s1350   .byte FE FD FB F7 EF DF BF 7F
 1358           .byte 00 00
 



    Joystick

 Currently real joystick is only available on Linux.
 The virtual joystick (using cursor keys) can be set to either joystick #1 or
 #2 with an option on command line, or any time from the Monitor.
 

    Paddles

From: msokos1@umbc.edu (sokos mark)
Subject: Re: Resistance values for joystick port


Phil Hoff  <phoff@ecst.csuchico.edu> wrote:
>macgyver@tartarus.uwa.edu.au (Antony Lord) wrote:
>> Does anyone know the (approximate) resistance values for the joystick 
>> port (i.e. pin 5 / 9 depending on if its 'pot AX' or 'pot AY') and the 
>> corresponding values of peek (54297) [or equiv peek]?
>The Commodore joystick only has two resistances - 0 and infinity. They
>are switches only. There are such things as analog joysticks, but not
>for the C64/128/VIC.

Nope, the first poster got it right. Unknown to most, the c64/128 is 
set up to handle both analog and digital joysticks (funny how an ancient
8 bit computer has more flexible ports than a modern big blue piece
of ****, but I digress). I've only ever seen one analog joystick made
for the c64, and that was ages ago. I don't even recall who made it
or any details.

Analog joysticks use the paddle inputs, just as the first poster said.
The resistance should be 470k ohms. Paddle values are read through
locations 54297 and 54298. The commodore 64 programmers reference
has a nice routine you can use to read them on p.346. Note the comment
";FOR FOUR PADDLES OR TWO ANALOG JOYSTICKS". Commodore from the beginning
seemed to have analog joysticks in mind, they just never caught on.

I believe the values are fairly linear, but it's been a long while
since I've played with them. Hook one up and try it! :-)

- Mark Sokos (msokos1@gl.umbc.edu) 
  Electrical engineer, computer geek (er, programmer) in training, 
  no-talent bum musician (have bass, will travel), and perpetual student


From: pre7874@u.cc.utah.edu (Perry Eidelbus)
Subject: Re: Resistance values for joystick port
Date: 11 Nov 1995 10:03:08 GMT

Antony Lord (macgyver@tartarus.uwa.edu.au) wrote:
: Does anyone know the (approximate) resistance values for the joystick 
: port (i.e. pin 5 / 9 depending on if its 'pot AX' or 'pot AY') and the 
: corresponding values of peek (54297) [or equiv peek]?

On my 64 (I am not sure if this is valid for others, and I'm too scared to
test my 128D), a resistance of x Kohms would give a PEEK value of x, i.e.
33Kohms = 33.  I verified this with my multimeter; I'd also take a
resistor of unknown value, measure it on the joystick port, then verify it
with my meter.  Although the value would be a little jittery (plus or
minus 1), it was always right.  It seems pretty strange to me that the 
ratio would be 1:1, and I've never seen this mentioned by anyone else.


Perry-beast



  8. SERIAL BUS PERIPHERALS

  The most common peripherals, i.e. printers and 1541 disk drives are
  included in the emulation. There is no CPU for the disk drive.

  X64 supports both RAM expansion and game cartridges. However, C64
  modules cannot be used with x128, nor x128 has 80 column display,
  since is it possible to get over 1.6 MB executables even without
  any doubled emulation.

  It is even possible to change between different kernel versions.


  8.1 Serial bus

   CBM Serial Bus Control Codes

	20	Talk
	3F	Untalk
	40	Listen
	5F	Unlisten
	60	Open Channel
	70	-
	80	-
	90	-
	A0	-
	B0	-
	C0	-
	D0	-
	E0	Close
	F0	Open



    How the C1541 is called by the C64:

	   read (drive 8)
		/28 /f0 filename /3f
		/48 /60 read data /5f
		/28 /e0 /3f

	   write (drive 8)
		/28 /f0 filename /3f
		/28 /60 send data /3f
		/28 /e0 /3f

    I used '/' to denote bytes sent under Attention (ATN low).

	28 == LISTEN command + device number 8
	f0 == secondary address for OPEN file on channel 0

  Note that there's no acknowledge bit, but timeout/EOI handshake for each
  byte. Check the C64 Kernel for exact description...
 

  X64 Traps

  Traps are wedges to the operating system for better performance. They
  are marked by writing a zero (BRK instruction) into the address where
  the execution has to be directed to an replacement routine.

Type	Name		Kernel Routine			Address	 Checkbytes
							{VIC20, C64, C128}


 * Kernel idle traps

TRAP	trap_idle_E5D4	Input From Keyboard		-
							E5D4	F0 F7 78
							-

 * Serial module traps.  

  The serial device interface consists of traps in serial access routines
  TALK, ACPTR, Send Data, and Get Data, so that actual operation can be
  controlled by C routines.  Serial.c implements the I/F control whereas
  the required acknowledge is supplied with the peripheral emulators.
  To support turboloaders, it would be necessary to emulate the serial port
  itself. That is much slower though. :(
  The PET doesn't use traps as the parallel IEEE488 can be emulated as
  a hardware without slowing down.


TRAP	SerialListen	TALK: send TALK/LISTEN		EE2E	20 A0 E4
							ED24	20 97 EE
							E355	20 73 E5

TRAP	SerialSaListen	TALK: send Secondary Address	EE40	20 8D EF
							ED36	78 20 8E
							E37C	20 73 E5

TRAP	SerialSendByte	Send Data on Serial Bus		EE49	78 20 A0
							ED40	78 20 97
							E38C	20 73 E5

TRAP	SerialReceiveByte
			ACPTR: receive from serial bus	EF19	78 A9 00
							EE13	78 A9 00
							E43E	20 73 E5

Return OK		Send Data on Serial Bus		EEB2
							EDAB
							E5BA

Return Error		Flag Errors			EEB4
							EDAD
							E428

 * Serial loop-back traps

TRAP	Serial Ready	Get serial data and clk in	E4B2	AD 1F 91
			(TKSA subroutine)		EEA9	AD 00 DD
						     E4F5,E569	AD 00 DD

Return OK		Get serial data and clk in	E4BB
							EEB2
							E572


 * Tape Unit Traps

TRAP	Find Any Header					F7B2	20 C0 F8
							F72F	20 41 F8
							E8D3	20 F2 E9

TRAP	Write Header					F83B	20 EA F8
							F7BE	20 6B F8
							E96E	20 1C EA

TRAP	Tape Receive Byte				F90B	20 E7 F7
							F8A1	20 BD FC
							EA60	20 9B EE

TRAP	Ask Play On Tape (unused)			-
							F81E	20 2F F1
							-


 * I/O Redirection traps

TRAP	LP2 - Get Character From Keyboard Buffer	E5CF	AC 77 02
							E5B4	AC 77 02
							C244	AC 4A 03



  8.2 DISK DRIVE

  8.2.1 The 1541


  Full manual is located at ftp.funet.f:/pub/cbm/documents/oc-118.manual



  How do I get Error Number ?

	10 OPEN 15,8,15
	20 INPUT#15, EN, EM$, ET, ES
	30 PRINT EN, EM$, ET, ES
	40 CLOSE 15

     Where:
	EN = error number.
	EM$ = error message string.
	ET and ES = track and sector where the error ocurred.



  8.2.2 The 1571

Upon power-up, the C128 sends code FF on the serial bus using the fast serial
protocol and sees if anybody understood.
The 1571 checks for the presence of the fast serial clock, and if present goes
into 1571 mode, acknowledging this to the C128 too. Otherwise, it stays in the
1541 mode.  If not connected to a computer or connected to a 64, on or off, it
will end up in 1541 mode. You must issue the software command to put it in 1571
mode.

	1541 mode
	  open15,dev,15,"u0>m0":close15  

	1571 mode
	  open15,dev,15,"u0>m1":close15

	Where 'dev' is the drive's device number, normally 8.


From: ceejack@crl.com (Jack Vander White)
Subject: Re: 1571
Date: 8 Feb 1996 09:53:37 -0800


: OK, another dumb question.  Does the 1571 read both sides without 
: flopping a disk??  know some PC's do that, and yes I read my 'book', but 
: do not know what it is telling me, I guess.  Have only used 1541's before, 
: and just realized from stuff I read here that the 1571 has 2 heads?


There are several parts to that answer.
  
1. Yes, the 1571 is capable of reading both sides of a disk.
  
2. On a 128 in 128 mode if you format a disk it will format in double 
sided mode and have twice as many blocks as a 1541 disk.
  
3. On a 64, or if you go to 64 mode on a 128 by holding down the logo 
key at startup It will switch to 1541 mode and read only one side. 
If you format a disk in this mode it will format as a 1541 single sided
disk.

4. It will not, in either 64 or 128 mode read the second side of a 1541
disk that was formatted by flipping it over unless you flip it over.
  
5. There are a set of commands called "U" commands for the 1571 that
you need to learn.

D#=Device Number, substitute the device number your 1571 is using for this.
   
SET 1541 MODE    OPEN 15,D#,15,"U0>M0":CLOSE 15
SET 1571 MODE    OPEN 15,D#,15,"U0>M1":CLOSE 15
SET to HEAD #0   OPEN 15,D#,15,"U0>H0":CLOSE 15
SET to HEAD #1   OPEN 15,D#,15,"U0>H1":CLOSE 15
  
If you set to 1571 mode in either 128 or 64 mode it will read, write and 
format the disk as a double sided 1571 disk with twice as many blocks.
However, you can still only have 144 files on the disk.
  
If you set to 1541 mode in either 128 or 64 mode it will read, write and
format the disk as a single sided 1541 disk. If you then set it to Head
#0 and format and then set it to head #1 and format it will format each
side as a 1541 disk and you can store 144 files on each side. However,
what you put on side 2 can not be accessed by a 1541 disk drive. It will
be recorded backwards to the way a 1541 reads.
   
There are several reasons why the use of the above is not recommended:

1. Some early 1571 ROMS have trouble accessing side 2. 
2. When using a program it will cause problems unless the program is
set up to handle disks formatted this way.
3. There are very few copy programs that can copy data from/to disks
formatted this way.
  

The only dumb question is the one you don't ask because you think it's dumb.

Jack VW
  


   C128 Disk Autoboot

 When the C128 is turned on, it automatically reads bytes 0-2 of sector 0
 from track 1 on the disk to see whether those bytes contain the codes for
 characters CBM. If the signature bytes are present, the system then looks
 at the bytes following them for the filename of a program to load and run.

 The autoboot is performed by Kernal BOOT_CALL routine. This routine tries to
 read track 1, sector 0, also known as the boot sector, from disk on drive
 #8 into the C128's cassette buffer (located at $0B00 in bank 0). If no disk
 drive is present, or the drive containd no disk, or the signature does not
 match, BOOT_CALL terminates.



  8.2.3 Other Drives

 None implemented yet.


  8.2.4 Filesystem Drive

 Supports LOAD, SAVE and loading the directory.
 By default this unit appears as the last drive, #11.



  8.3 PRINTER

  Below are the possible alternatives for both Charset and Locale.
  Only conversion to ASCII and ISO Latin/1 charsets is implemented.


    Locale

  This setting affects the printer emulation most.

	7-bit Charsets
	    ASCII
	    ISO 646-FI (SF-1)
	    DEC 7-bit

	8-bit Charsets
	    ISO 8859-1 (Latin-1)
	    MSDOS, Atari ST
	    Macintosh
	    Roman 8
	    EBCDIC -family

	16-bit Charsets
	    None will be implemented on the VICE.


    International Charsets

	Charset			MPS803	Star ??	 Star LC10C

	Commodore		  x		   x
	Commodore-DIN			 	   x
	Denmark-1			  x	   x
	Denmark-2				   x
	England				  x	   x
	Finland				  x
	France				  x	   x
	Germany				  x	   x
	Italy					   x
	Norway				  x
	Spain					   x
	Sweden-1			  x	   x
	Sweden-2				   x
	USA				  x	   x


    International Character Codes

 -----------------------------------------------------------------------------
 Code	Char Name	 CBM GER  DEN1  DEN2 FRA ITA SPA  SWE1  SWE2 USA ENG |
 -----------------------+--------+----------+------------+----------+--------|
 c6  	/AE		|        |5B/7B  5B |            |          |        |
 c4  	/Adieresis	|     5B |          |            |5B/7B  5B |        |
 c5  	/Aring		|        |5D/7D  5D |            |5D/7D  5D |        |
 c9  	/Eacute		|        |          |            | 40    40 |        |
 d1  	/Ntilde		|        |          |         5C |          |        |
 d6  	/Odieresis	|     5C |          |            |5C/7C  5C |        |
 d8  	/Oslash		|        |5C/7C  5C |            |          |        |
 dc  	/Udieresis	|     5D |          |            |          |        |
 -----------------------+--------+----------+------------+----------+--------|
 e4  	/adieresis	|     7B+|          |            | 5B+   7B+|        |
 e6  	/ae		|        | 5B+   7B+|            |          |        |
 e0  	/agrave		|        |          | 40  7B+    |          |        |
 e5  	/aring		|        | 5D+   7D+|            | 5D+   7D+|        |
 e7  c	/ccedilla	|        |          | 5C         |          |        |
 e9  	/eacute		|        |          | 7B+ 5D     |          |        |
 e8  	/egrave		|        |          | 7D+ 7D+    |          |        |
 df  	/germandbls	|     7E+|	    |		 |	    |	     |
 ec  	/igrave		|        |          |     7E+    |          |        |
 f1  	/ntilde		|        |          |         7C+|          |        |
 f6  	/odieresis	|     7C+|          |            | 5C+   7C+|        |
 f2  	/ograve		|        |          |     7C+    |          |        |
 f8  	/oslash		|        | 5C+   7C+|            |          |        |
 fc  	/udieresis	|     7D+|          |            | 7E+   7E+|        |
 f9  	/ugrave		|        |          | 7C+        |          |        |
 -----------------------+--------+----------+------------+----------+--------|
 --	/Pt		|        |          |         23 |          |        |
 40  @	/at		| 40*    | 40    40*|     40  40 |          | 40  40 |
 5c  \	/backslash	|        |          |     5C     |          | 5C  5C |
 7c  |	/bar		|        |          |            |          | 7C  7C |
 7d  }	/cclose		|        |          |         7D+|          | 7D  7D |
 7b  {	/copen		|        |          |            |          | 7B  7B |
 a4  	/currency	|        |          |         7B+| 24    24 |        |
 98  "	/dieresis	|        |          | 7E+        |          |        |
 24  $	/dollar		| 24  24 | 24    24 | 24  24  24 |          | 24  24 |
 a1  	/exclamdown	|        |          |         5B |          |        |
 23  #	/hash		| 23  23 | 23    23 | 23  23     | 23    23 | 23     |
 bf  	/questiondown	|        |          |         5D |          |        |
 9a	/ring		|        |          | 5B  5B     |          |        |
 a7  	/section	|     40 |          | 5D         |          |        |
 5d  ]	/sqclose	| 5D     |          |            |          | 5D  5D |
 5b  [	/sqopen		| 5B     |          |            |          | 5B  5B |
 a3  	/sterling	| 5C*    |          |            |          |     23 |
 7e  ~	/tilde		|        | 7E+   7E+|         7E+|          | 7E  7E |
 -----------------------+--------+----------+------------+----------+--------|
 Code	Char Name	 CBM GER  DEN1  DEN2 FRA ITA SPA  SWE1  SWE2 USA ENG |
 ----------------------------------------------------------------------------


    Notes:
	40	Section in CBM-DIN
	40	Eacute in Denmark-II ASCII (?)
	5C	Backslash with CBM charset in DIN and ASCII modes.
	5B/7B	Denotes Uppercase/Lowercase equivalence.
	+	Marks code only available in Lowercase mode.

    Note: These character sets are available on the Star emulation
	 (with 8x8 charsize) only.



    Print Pitch

From: aa122@detroit.freenet.org (John F Davis)


>I'm looking to buy a used, good condition 80 dpi (C= ready if possible)
 
You are just about asking for the impossible as the C= standard is 60dpi
so most C= ready printers are only 60 DPI.
 
However a 80 dpi printer (IE, Star Gemini SG-10 with a decent interface
(Mine has a Xetec JR on it) works GREAT and with every piece of software I got
In a very, very few cases (Read that ONE, I think) I have to pre-LOCK the
interface in "Transparent" with a simple command outlined in the manual

    open 4,4,25:print#4,"locked":close4 :rem (you can just send print#4," ")

-- 
   John F Davis In Delightful Detroit, Mi.    aa122@detroit.freenet.org


  8.3.x Graphics

 Command Operand		Bits MSB cpi

  27 75     n1 n2 m1 ...	  8  top  60
  27 76     n1 n2 m1 ...	  8  top 120
  27 89     n1 n2 m1 ...	  8  top 120   Double speed
  27 90     n1 n2 m1 ...	  8  top 240

  27 42  n0 n1 n2 m1 ...	  8  top
	n0 = 0			 Same as 27 75
	n0 = 1			 Same as 27 76
	n0 = 2			 Same as 27 89
	n0 = 3			 Same as 27 90
	n0 = 4			  8  top  80   CRT Graphics

      8     m1 ... 14/15	  7  bot  60
      9     m1 ... 14/15	  7  bot 120
  27 18     m1 ... 14/15	  7  bot  60   Same as <8> but reversed image.

     26     n1 m1		  7  bot  --   Used inside the 7-bit commands.



  9. FILE COMPATIBILITY

  X64 provides complete backward compatibility, but the implementation of new
  operating modes requires system files that are not interchangeable. There
  must be separate RAM and ROM (including modules) images for each program.
  The RAM expansion and disk images are the same.

  However, as there are several emulators for different platforms, all files
  cannot be made directly usable. Utilities to convert those back into CBM
  binary exist already. Check out the comp.emulators.cbm FAQ for more info.

  Below is description of the most common file formats. some of them are
  supported, the others are just for reference.



  9.1 Commodore 64 ROM Images

    X64 ROM Image Set

  The ROM images are recognized by their names, 'basic' and 'kernel'.
  These files are searched in the Project Directory, which defaults to "C64".
  For x64 they are 8192 bytes long each, containing the binary data of
  the original ROMs of a machine from C64 series. The default load address
  in the beginning of the files is allowed, and skipped when reading the
  file. Character ROM image is not used.

  One can use many of the different Kernel versions via '-revision' option
  on command line. Once the kernel is loaded, it's patched to the desired
  version.

  Altough any of the original C64 kernels can be used, this does NOT apply to
  the third-party products. README tells more about this subject.

  NOTE:
   The ROMs _MUST_ be for the same CBM machine as the program emulates.
   They cannot be interchanged because e.g the memory management and I/O are
   completely different on each machine.
 
   ROMs from another emulators -- like romcode.c64, A64 ROMs, ... -- are
   usually invalid. (It may be possible to get the ROMs on some FTP site
   though. I.e. roms.zip on frodo.hiof.no in emulation directory, or the
   ROMs (numbers listed in README) in firmware/ directory on ftp.funet.fi.
   Your mileage may vary.)


    C64S Romcode

  The file called 'romcode.c64' contains copies of total 4 ROMs, which
  makes it 36864 bytes long.
  The kernel image in this file is modified, and thus it cannot be used
  for any other purposes than for C64S emulator.

      Offset	Bytes	Description

	  0	16384	disk drive rom
      16384	 4096	chargen rom
      20480	 8192	basic rom
      28672	 8192	kernel rom


    Mac64 ROM Resource File

  In addition to miscellaneous data, the 6510.rsrc file contains the C64 ROM
  images. In version 0.4 they seem to be located in the following places:

	 $0422 - $2421 BASIC
	 $342a - $5429 KERNEL


    A64 romcode

  Since A64 uses kernel emulator instead of actually running the 6502 ML,
  the A64 ROM files only contain some lookup tables, not the real ROM data.


  9.2 Commodore 128 ROM Images

    X128 ROM Image Set

  The ROM images are recognized by their names, 'basic' and 'kernel'.
  These files are searched in the Project Directory, which defaults to "C128".
  For x128 they are 36864 and 8192 bytes long respectively, containing the
  binary data of the original ROMs of a machine from C128 series. The default
  load address in the beginning of the files is allowed, and skipped when
  reading the file. Character ROM image is not used.

     C128 BASIC Revisions

  Both revisions of 85 and 86 are supported.


     Nationalized C128 Kernel ROM Versions

  Supported Kernel Revisions:
		Rev 1 American
		Rev 1 German
		Rev 1 Swedish


  9.3 Commodore Plus/4 ROM Images

  None exists.


  9.4 Commodore VIC-20 ROM Images

  The ROM images are recognized by their names, 'basic' and 'kernel'.
  These files are searched in the Project Directory, which defaults to "VIC20".


  9.5 Commodore PET ROM Images

	"Kernel"	Columns		Basic	Basic ROM	Kernel
	--------	-------		-----	----------	-------
	pet3032		  40		 1.0	$C000-E7FF	F000-FFFF
	pet4032		  40		 2.0	$C000-E7FF	F000-FFFF
	pet8032		  80		 4.0	$B000-E7FF	F000-FFFF

 Care must be taken as the same program emulates all of these three PET
 models. One has to select the correct display mode according to the number
 of columns supposed by the ROM used. Default value is 40 columns.
 With 'well-known' kernel revisions, that are detected via checksums,
 no command line switch is necessary. A command line switch overrides
 the autodetection, though.

 To avoid confusion, each of these ROM images contains all roms needed on a
 specific PET model; thereby no Basic image is used.



  9.6  *.C64 Image File		Total Size: unknown

  Not supported. (PC64 game format.)
  No further information available.

  Win64 uses this extension for the actual CBM binary files.
  See Section 9.10 below.


  9.7 X64 Ram File		Total Size: RAMSIZE + 4103

  Upon startup x64 searches for a file called "ram", containing the RAM
  memory from a previous run. If one is not available, a cold start (the
  normal power boot-up) is required. A ram image from clean run (not eg.
  a freezed demo) is, however a vital resource for advanced use of x64,
  since it makes possible to skip the RESET sequence.
  The inbuilt monitor treats this file somewhat differently, since it
  also saves and restores the state of I/O area as well as the 6510
  registers. That makes it possible to use so called snapshot images.

      Offset	Bytes	 Description

	 0	RAMSIZE	 contents of the RAM
     RAMSIZE	4096	 I/O area with shadows
		 7	 CPU Registers: PC (LO/HI), AC, XR, YR, PS, SP


  Draft for VICE Snapshot Format  -- Preliminary data.

  Another file format with exact snapshot has been planned, but it's
  not fully defined yet. Below is a briefing.

      Offset    Bytes   Description

	 0	 6	ID Code
	 6	 2	Reserved
	 8	 2	Header version
	10	 1	Snapshot version
	11	 1	Snapshot type (device number etc)

	12	20	Pointers (HI/LO)
	32	 8	Configuration bit masks
	40	40	CPUs
	80	48	OS/Kernel info
	128	128+	Flags for peripherals, special features, etc.

	256+	RAMSIZE	Contents of the RAM
	?	4096	I/O area
	  the rest	16384, (32768) or 65536 bytes of VDC RAM in C128 dump

  Note: This RAM format draft description is shown only for information, and
	thus it should not be used as any reference yet!



  9.8 Disk Image Files

    X64 Disk File	Total Size: 174912

 VICE uses special disk image format commonly called "X64" as it was
 introduced by that program. It was originally created by Teemu Rantanen, for
 his own emulator.
 Because of the header, this format is superior to the standard D64.


      Offset	Bytes	Description

	 0	 4	Magic Header: 'C', 0x15, 0x41, 0x64

	 4	 2	Image Format Version:
			   C1541 Version Major
			   C1541 Version Minor

	 6	 1	Disk Type:
			   0 = 1540
			   1 = 1541	(Default)
			   2 = 1542
			   3 = 1551

			   4 = 1570
			   5 = 1571
			   6 = 1572

			   8 = 1581

			  16 = 2031,4031
			  17 = 2040,3040
			  18 = 2041

			  24 = 4040

			  32 = 8050
			  33 = 8060
			  34 = 8061

			  48 = SFD 1001
			  49 = 8250
			  50 = 8280


	 7	 1	Maximum Tracks on each Side
			   1540,1541,1570:	35
			   1571:		35
			   1581:		80 (Logical single-sided disk)
		
	 8	 1	Number of Disk Sides
			   0 = single sided
			   1 = double sided
			This value must be 0 for all 1541 and 1581 formats.

	 9	 1	Error Data Flag
	10	22	Unused, must be 00
	32	31	Disk Image Description (in ASCII or ISO Latin/1)
	63	 1	00

	64		683 (or 768) disk sectors with 256 bytes each
	xxxx   #Blocks	Error Data Bytes for each Block


 For descriptions longer than the above 31 characters, put them in a file on
 the disk image.



    *.D64 Disk File	Total Size: Different sizes

  The C64S disk images consist of only the binary data for sectors and
  optional error data block in the end.
  They can be converted into the right format with c1541 via -cr option.

     Size	Description

     174848	35 tracks
     175531	35 tracks + 683 bytes error information
     196608	40 tracks
     197376	40 tracks + 768 bytes error information
     206080?	42 tracks
		42 tracks + 802 bytes error information

  See "File Conversions" section for details in converting these formats.



	Proposed New .D64 Format		[ Draft - May 1995 ]

This is the proposal for a new D64 file format. The extension should
be changed to D69 or something to avoid mixing with the old format.

Advantages over the old format:
- supports any number of formatted tracks
- supports half tracks
- supports GCR coded tracks
- supports compressed tracks
  RLE decompression is fast, the files remain zippable
  LZW decompression is slower but tighter, also needs some memory
- supports write protection flag (no dos messing necessary any more)
- users can atach info text
- does NOT support multidisk images, as it is not practical from the
  emulator's point of view
- open for future extension

Please email any suggestions to: miha@ferlin.fer.uni-lj.si


	[File header]
	Offset, Size, Info
	     0, 14    sign: "New D64 File", 0, 1A
	    14, 2     file type (lo/hi)
	              0x0100 = 01.00
	    16, 24    user name
	    40, 4     offset of info text (0 = no info attached)
	    44, 1     contents type
	              0 = empty (invalid!)
	              1 = 1541 formatted disk
	              2..255 = reserved
	    45, 1     write protected
	              0 = no
	              1 = yes
	    46, 2     number of track entries
	              normal 1541 disk: 88 entries, used entries: 0, 2, 4,
			 ... 66, 68

	    48, 16    reserved

	    xx, 8*n   track entries (n = number of track entries)
	    xx, xx    track data (for each track)

	[Track entry]
	Offset, Size, Info
	0, 1    track type
	        0 = empty
	        1 = simple, decoded sectors
	        2 = simple with error info, decoded sectors + read codes
	        3 = RLE coded sectors + read codes
	        4 = LZW coded sectors + read codes
	        5 = GCR, raw 1541 coded data
	        6..255 = reserved
	1, 1    type data
	        type 0: reserved (0)
	        type 1,2,3,4: number of sectors in track
	        type 5: reserved (0)
	2, 2    track data size
	4, 4    file offset of track data

	[RLE coding]
	initial magic byte MB = $BD
	initial data = 0
	unpacking input -> output
	  data <> MB -> data
	  MB 01 -> MB, MB = MB + $13
	  MB 02 -> MB MB
	  MB nn -> nn * last data (nn = 0 equals nn = 256)

	[LZW coding]
	the coding is similar to GIF coding
	4096 dictionary entries
	the first 256 entries are byte equivalents
	when the dictionary is full it is cleared immediately (no clear codes)

	[GCR coding]
	the coding is the same as used by 1541 internally

	[New D64 handling strategy]
	- the emulator must be able to read all track types
	- any track can be saved anywhere within the file
	- byte coded tracks are saved in type 2 when changed
	- GCR coded tracks are saved in type 5 when changed
	- an external utility is provided to pack/unpack/optimize D64 files




    GEOS File Format

	Peter Schepers	(schepers@dcs1.uwaterloo.ca)
	Andreas Varga	(e9426444@stud1.tuwien.ac.at)
	Peter Karlsson	(m9944@abc.se)


 The directory entry layout for GOES uses the unused bytes in the normal dir
 entry (1541) for info.
 The exact order is the same as CMD uses in their device's directories.

 Another byte (somewhere after the file name) tells GEOS if the file is a 
 plain sequential one ($00) or if it's a GEOS VLIR-file ($01) 
 (that's Variable Length Indexed Record).
 These GEOS files have a table of tracks and sectors in the first sector.


	Dir entry of a GEOS disk

	Hex		Description

	0-1		Not used
	2		File Type
			   0x = scratched/splat, 8x = alive, Cx = locked
		           where x: 0=DEL, 1=SEQ, 2=PRG, 3=USR, 4=REL)
	3		First Track
	4		First Sector
	5-14		Filename, padded with shift-space
	15-16		Info block track and sector
			   REL files:  side sector
			   GEOS files: information sector
	17		VLIR File  (Variable Length Indexed Record)
			   REL files:  record length
			   GEOS files:

	18		GEOS files: Creation year-1900 (1 byte)
	19		GEOS files: Creation month : 1..12 (1 byte)
	1a		GEOS files: Creation day   : 1..31 (1 byte)

	1b		Temporary storage of track during @SAVE
			GEOS files: Creation hour  : 0..23 (1 byte)

	1c		Temporary storage of sector during @SAVE
			GEOS files: Creation minute: 0..59 (1 byte)

	1d		GEOS files: Creation second: 0..59 (1 byte)
	1e-1f		File Size (Number of blocks in file)


> What does the single sector (pointed to by the second t/s entry) contain ?

It points to the info-block (always one sector) which contains details of
the file, like loading address, start address, end address, 
GEOS filetype (application, printer driver, document,...), and the text 
you can enter in the file/info dialog in DeskTop.
Just copy this sector, and let the dir entry point to it.


> What is the format of the VLIR filetype?

The track/sector bytes that normally point to the start of a file, point 
to the VLIR index block.
The 254 bytes of the index block can point to 127 different files on the 
disk, which all belong to this VLIR file.
(multiple files in one file...)

so the index block can look like this:

	00 ff 02 03 04 05 06 07 00 ff .........
	..............

The first two bytes are not used (i guess, I'm not completely sure)
The third and the fourth byte point to track 2, sector 3. There you'll 
find the beginning of a normally linked file (this doesn't show up in the 
dir of course)
The next two bytes point to 4/5, and so on until you reach 00 ff (or 
maybe it's some other ending, I don't fully remember)

To give an example: GeoWrite uses VLIR files to store documents. The 
first 64 entries in the index block point to a maximum of 64 pages, the 
latter 63 entries point to a maximum of 63 inserted pictures.





  9.9 Tape Image Files		Total Size: Varies

 VICE uses T64 and P00 tape images. In addition, c1541 can be used to copy
  to a disk image files from *.t64 tape images that follow this structure.


    *.t64 tape image

 T64 images are supported read-only.
 
      Offset	Bytes	Description

	 0		64 byte Tape Record:

	 0	32	Tape description
			  "C64 tape image file"
			  "C64S tape file"
			  "C64S tape image file"

	32	 2	Tape version: $0100
	34	 2	Max number of files, in LO/HI
	36	 2	Number of existing files, in LO/HI
	38	 2	 -
	40	24	User description


	64+n*32		32 byte Directory Slots for each file:

	 +0	1	Slot allocation flag:
			  00 = free entry
			  01 = normal tape file
			  02..FF = memory snapshots
	 +1	 1	File type
	 +2	 2	Start address in C64 memory, in LO/HI
	 +4	 2	End address in C64 memory, in LO/HI
	 +6	 2	 -
	 +8	 4	File start address on the image, in LO/HI
	+12	 4	 -
	+16	16	C64 filename



  9.10 Program File		Total Size: Varies

    CBM Files

  X64 uses the standars CBM program files containing load address in
  the first two bytes.


    *.P00, *.S00, etc.

  This is program file for the 64NEU/PC64. These files are supported on x64
  version 0.3.2 and later. To extract the original, remove the first 26 bytes.

      Offset	Bytes	Description

	 0	  8	String "C64File" terminated by 00.
	 8	 17	Original C64 Filename.
	25	  1	Record size for REL files.
	26	varies	Original file



  9.11 SID Music Files

    Playsid

  From: 3schwend@rzdspc63.informatik.uni-hamburg.de (Michael Schwendt)
  There is no documentation about the PSID files in SIDPLAY.DOC !!!
  But this C structure should help.


/*                                        */
/* PlaySid 'single-file' header support   */
/* Copyright (C) 1994,95 Michael Schwendt */
/* All rights reserved.                   */
/*                                        */

typedef signed char byte;
typedef signed short int word;
typedef signed long int dword;

typedef unsigned char ubyte;
typedef unsigned short int uword;
typedef unsigned long int udword;

struct psid_hdr  {
 char id[4];                    /* 'PSID' */
 ubyte version, versionlo       /* 0001 oder 0002 */
 ubyte datahi, datalo;          /* 16-bit offset to binary data in file */
 ubyte loadhi, loadlo;          /* 16-bit C64 address to load file at */
 ubyte inithi, initlo;          /* 16-bit C64 address of init subroutine */
 ubyte playhi, playlo;          /* 16-bit C64 address of play subroutine */
 ubyte songshi, songslo;        /* number of songs */
 ubyte starthi, startlo;        /* start song (1-256 !!) */
 ubyte speedhihi, speedhilo,
       speedlohi, speedlolo;    /* 32-bit speed info (0=50 Hz, 1=60 Hz/timer */
 char name[32];                 /* ASCII-strings, NULL-terminated ? */
 char author[32];
 char copyright[32];
/* only version 2+ */
  uword flags;			/* Sidplayer song 0=No, NZ=Yes */
  udword reserved;
};



  9.12 CBM Archive Formats

 Complete list is available in the comp.sys.cbm General FAQ.


From Phil Hoff  <phoff@ecst.csuchico.edu>

.a65 is an ASCII file of 6510 source code.


From: Bruce Gingery <bruce@TotSysSoft.com>
Date: 10 May 1995 14:22:51 GMT


   an ".sfx" file is USUALLY a self-extracting archive.
This extension is CURRENTLY being used also by Mac users
for a self-extracting .hqx or any self extracting Mac archive.
It is also the self-extracting .LZH written by Chris Smeets.
and should work either on a C=64 or C=128-in-128-mode.

   an ".sda" file is either an older "SDN"(sm) file description
from the Software Distribution Network on Fido and other modem
nets, or a self-extracting archive either from Q-Link or from
Chris Smeets' Commodore ARC program.  Should extract on a C64
by running it, (or on a C128 in 64 mode).

   an ".lzh" file MAY be extracted (if the sfx header matches)
by pre-appending the operational extraction code from a Smeets
SFX archive, or MAY be extractable with his lharc compatible tools.
This was originally a DOS 8+3 filename supporting format - an
extension from Lzari's LZS archive format, but has since been
extended to utilize any of THREE header formats, probably only
the first of which is supported on C= (last I checked).

   'C' source is freely available on the net to handle ALL of the
LZH format archives and headers.  The only SFX compression that
I've seen supported is -LH1-, but then I haven't been well C=
connected in some time.

    Type-3 headers are the best - as they can include extension
segments to handle ANY filesystem's specifics.

    .lha  is the Amiga defacto standard for .lzh and can USUALLY
be handled the same way, but uses Type-3 headers and usually 
contains an ".info" file.

   .ARC is either a Commodore archive or a PK/SEA style archive
using LZW compression and creation of new tools to handle it
are likely to run into the Unisys patent problems if distributed
other than for free.  CSARC should handle the DOS style versions
created by CXARC (forget the spelling on it) or by arca, ARC.EXE
(System Enhancement Associates) or PKArc which supposedly is not
still around because of an old lawsuit.

   .ZIP is a file created by PKZIP or one of its clones - there
MAY be tools for C64/128 for them.  My AV package will VIEW
the archive headers if you can find it, but will only tell you
what's contained, not extract the files

   .tgz is a Unix "tar" file compressed with GZip.  Not positive
where you'd find either for C64/128 but the source code for both
is freely available on the net.  This is identical to .tar.gz

The .gz extension indicates the file has been compressed with the Gnu zip
utility, gzip.  In an OS that supports gzip (DOS, Unix, Mac).


   .tar.Z (or .taZ) is a Unix "tar" file compressed with Unix
"compress", virtually identical to .tgz except that the compression
is like ARC.

    .lnx is a Lynx/Links file (not to be confused with the WWW
browser of the same "Lynx" name).  Essentially it is a series
of CBM files concatenated together by having their last block
pointer changed, and a header stuffed on the front... no compression.



From: schepers@dcs1.uwaterloo.ca (Peter Schepers)
Subject: 64COPY and different file types.
Date: Thu, 9 Nov 1995 14:01:19 GMT


I have seen a lot of postings lately lamenting the fact that 
some people don't know about the various C64 filetypes that are
used on some C64 sites. I will attempt to give a brief instruction
in them, and how to deal with them.

1. LNX... created on the C64 with a program called Lynx (or
Ultimate Lynx). These files are typically found on the BOT's,
not on the traditional FTP sites (PITEL would be the exception).
You can download the file UNLYNX.ZIP from various sites to 
split these files apart. 
  If you view these files with a HEX viewer, you will see the text
message saying something like "LYNX 17" or "ULTIMATE LYNX" or some
such thing. You might also be able to see the filenames that are
contained in the file.

2. #!xxxx... also know as ZipCode. The name attributed to this
filetype is unfortunate and misleading since the name ZIP to us DOS
users usually means PKZIP, the compression program. This filetype
has nothing whatsoever to do with this.
   These files always travel in groups of 4 (standard ZipCode) or 6
(called a 6-pack). The 6-pack is very rare, and I have never seen them.
If you have a file that unpacks to less than 4 ZipCode files, you 
likely have a bad file.
   The filename is very distinctive, starting with a number, usually
1-4, then an exclamation (!) sign, and part of the real filename. That is
why I use the #!xxxx to denote the filename, since it varies so much
in look, but if you see a ! as the second character of the filename,
it is in all likelihood a ZipCode file. 
  You can download ZIP2DISK.ZIP from various sites to handle these files.

3. Binaries... These files are usually denoted by no extension at all,
just a filename. If you investigate the file by viewing with a HEX
editor, you will generally find the first two bytes to be 01 08, the 
usual load address for the C64. You might also find some BASIC code
at the beginning, such as a series of 4-5 numbers about 12 bytes in, 
denoting a SYS call from BASIC. 
   The only way to handle these files is to convert them into one of
the emulator formats, like T64, D64 or P00 (for PC64). You could also
UNLIST the file back into BASIC using 64COPY. Position the hilite bar 
over the filename, and press SHIFT-F3. A text file will be created with 
the contents of the BASIC listing, which you can view with a text editor.

4. LHA... these files are created with LHA on the C64, and can be
uncompressed on the PC with LHA213, but you might run into problems.
The C64 version of LHA stores *LONG* filenames into the archive, and the
DOS version, while it won't complain about the length of the name, won't
create a file of more that 8 characters + 3 extension. Obviously this will
create difficulties if the filenames are very similar, since as they are
created under DOS, each new one will wipe out the one previously created,
without asking first (since to LHA the filenames are different).
   The way around this is not easy. You need to partially extract the files, 
and hit CTRL-BREAK to stop the extraction at various points. i.e. if the 
LHA archive contains 8 ZipCode files, where the first four get 
overwritten by the last four (which is *very* common). Follow these steps 
to extract:
      1. Allow LHA to extract all the files. You will left with the last 
four, since the first four will be overwritten. Move these files to 
another directory.
      2. Re-extract the files again, this time hitting CTRL-BREAK after 
the fourth file is done. Move the last three files (2!, 3!, 4!) to 
another directory. Don't take the 1! file since it likely is part of the 
second group.
      3. Re-extract the first files again, hitting CTRL-BREAK after the 
first file. Move the 1! file to the directory where the files from step 2 
went, leaving whatever is left. You can now convert the ZipCodes to D64's.
  You may find it takes practice to stop the LHA program at the proper 
points. Don't get too discouraged if you don't get it right away. It took 
me a while as well.

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

Now for the good news! My program 64COPY will handle most of these
filetypes (not LHA), and also convert between most of them. It will 
unlynx LNX files into either P00 files, or ZipCode files, depending on 
the contents. It will create D64 files from the multi-part ZipCode files. 
It will also convert between T64, D64, X64, Binary, P00.

To convert ZipCodes, position the hilite bar over *any* part of the 
ZipCode archive and press F11. The program will then ask if you want to 
convert the ZipCode/LNX. Say yes, and it will then ask for the filename 
to create (xxxx.D64). Press return and the file is created.

To convert LNX files, do the same as above. Press F11, and the files will be
extracted one at a time (to either ZipCode or P00, depending on the 
contents of the LNX archive).

To convert binaries, follow the same procedure, press F11, and now a 
different dialog box comes up, asking what format you want the file
converted to, be it D64, T64, P00, X64, or Binary. Select what you want and
you are done.

-----------------------------------------------------------------------------
 Peter Schepers,                 | 
 Dept. of Computing Services,    |   The opinions expressed in the above
 University of Waterloo,         |   rant are those of the poster, and not
 Waterloo, Ontario, Canada.      |   necessarily shared by anybody else on
 1-519-885-1211 ext 2456         |   this planet (or employer).




There are four major compression/archiving formats in the Commodore 64 realm.

 One of the most popular is LYNX which uses a .LNX extension.
 This format is not compressed but is a way of creating a single file from many.
 There are many versions (some conflicting) of LYNX.
  Library is very similar (usually .LBR or .LIB).
 ZIP (not to be confused with PKZIP)  is a compressed disk archive.
 A ZIP is broken into four files (and then usually LYNXed) the names are usually
 1!filename 2!filename and so forth.  There is a utility called ZIP2D64 which
 converts these to emulator disk images.

 Lastly is ARC, which is the old SEA archiver. It is horribly slow on the
 Commodore 64 and not widely used.   




> Is it possible to uuencoding files which are compressed (for exsamples
> sfx, sda, or zip)?

Yes, it is. For any uuencode program it doesn't matter what kind of files is
being uuencoded.


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

  uuxfer

From: ismael@CAM.ORG (Ismael Cordeiro)
Subject: Re: c64 files help needed
Date: 4 Oct 1995 14:21:30 -0400


probably the files you're trying to decode are in PETSCII.
 Uuxfer only handles ASCII files.

The two copies of uuxfer, binary and uuencoded, at ccnga.uwaterloo.ca
/pub/cbm/util64 work perfectly.


Ismael
|  ISMAEL CORDEIRO             |  Internet: ismael@cam.org  |


Subject: Re: Uuencoded files

> How to dissolve uuencoded files on c64 ?
> I have a program to uudecode (uuxfer), but my problem is downloading
> the encoded text.


To download, simply open a buffer, making sure it uses NO conversion, 
then save the buffer.  The problem with UUENCODED files on the C-64 is 
that the term program will convert standard 7 bit ASCII to 8 bit 
PETSCII.

	There are undoubtably UUdecode programs available for the 64.  Craig
Bruce's ACE has it built-in.  You could do it on your PC and then transfer
the program to your 64.  If you have a shell account you could decode it
there and then download it to the 64.  Finally, if you are referring to
"polygonamy", you can just FTP it from ccnga.uwaterloo.ca in directory
/pub/cbm/INCOMING/demos/polygonamy.

I just checked ccnga and there are indeed some uu programs in the c64utils
directory.



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

  10. PROGRAMMING / CONVERTING PROGRAMS

  10.1  Program file format conversions

    P00 -> CBM binary		dd bs=1 skip=26 if=FILE.P00 of=file

    Ascii text -> BASIC		petcat -w2 file.txt > file.bas
				petcat -w2 -o file.{bas,p00} file.txt



 This conversion is also provided on some transfer programs.



  10.2 Listing Basic Programs


 BASIC to SEQ or ASCII

  The natural way

If you still have your CBM computer or are now using an emulator, just "print"
a listing to a disk file and use that.

	load"program",8
	open2,8,2,"0:listing,s,w"
	cmd2
	list
	print#2
	close2

 this will create a seq file named filename (you may substitute any
 legal filename here)

 Note that in the 64's BASIC 2.0 anything on a line after `list' is ignored,
 so if if you want to concatenate the lines above, you'll have to break after
 "list" and start with "print#2" on a new line. Unfortunately, that means
 that the disk file will have a blank line and "ready." after the listing.

 That's not necessary in the 128's BASIC 7.0.  A 128 could have the entire
 string of commands on line line (and can avoid writing "ready." to the disk).

 If you use    print#8,""; :close 8   instead of just   print#8 :close 8 
 you'll avoid one more blank line in the disk file.  I don't remember, sorry,
 whether   print#8;:close8  will work.

 Also note the common mistake omitting the print# command (needed to unlisten
 the destination device after the cmd command). That can leave BASIC in a very
 confused state; the print# is indispensable.

 It is possible to get a sequential file of a BASIC program using some word
 processors, like The Write Stuff. See your word processor manual for details.
 You can load it into TWS format, and any TWS text file can be converted to Pet
 ASCII sequential.


  Emulators

 If you have no 64 anymore, there are 'disk-2-disk' for the Amiga, and 'petcat'
 (petcat-2.02.tar.gz) for Unix/Atari ST that will make the conversion.
 Or, if you insist in writing your own program, there is a list of BASIC token
 codes at x2ftp.oulu.fi:/pub/cbm/docs/cbm_basic_tokens.

 Don't forget that CBM uses special characters for cursor control, etc. and
 they won't translate properly without a special program - like petcat - to
 convert them to comments e.g. <CURSOR RIGHT>, etc.

 ---

 For more information on PETCAT, see the Text Conversion section and petcat
 manual.

 ---

From: 74171.2136@compuserve.com (Cris Berneburg)
Subject: new utility: TOK64
Date: Thu, 22 Feb 1996 19:37:11 GMT

OK, I've completed version 1.0 of TOK64.EXE, a utility to translate
pc ASCII text listings of C64 basic programs into native tokenized
basic programs that can actually be run on a 64 or emulator. Also
translates C64 basic programs back into ASCII text.

I've requested an upload to SimTel. I'd like to submit to FUNET, too.


Cris Berneburg		74171.2136@compuserve.com
http://ourworld.compuserve.com:80/homepages/pcgeek/
Manager of Project 64

 ---


  SEQ to BASIC


OPEN1,8,2,"YOUR-FILENAME,S,W":CMD1:LIST

When your cursor comes back:

PRINT#1:CLOSE1

This works for the 64 as well.
Note that this saves the file as PETSCII, not ASCII. You may need
to convert it using a text editor or via your terminal program
(e.g. CCGMS happily converts on the fly).

The second step is a little harder. There's a one liner that does
it for you on the 128, but the command has escaped me. When I want
to do something like that on the 64, I use a dynamic keyboard
approach like so:

1 REM -- LOADER SECTION. MAKE SURE TEXT FILE DOESN'T HAVE LINES 1-10.
2 OPEN1,8,2,"YOUR-FILENAME"
3 Z$="":L$=""
4 IF(ST=0)AND Z$<>CHR$(13)THEN L$=L$+Z$:GET#1,Z$:GOTO4
5 IF(ST<>0)OR L$="READY."THEN PRINT"OK":CLOSE1:END
6 PRINT CHR$(147)L$:PRINT"GOTO4":POKE198,3:POKE631,19:POKE632,13:POKE633,13
7 END

When you run this program (well, I did this from memory; you might
need to tweak it), you'll see the program slowly loaded from disk.
This is the pendulous method, but it works fine. You'll need to
substitute the requisite POKEs for the 198 and 631 sequence (I
think it's 208 and 842, but I can't remember exactly).

Hope this helps.

Cameron Kaiser
ckaiser@ucsd.edu



     --I'm not entirely sure, but I think what you're trying to do is to
add the linefeed after carriage return that IBM or MAC ASCII requires but 
CBM doesn't, then removing the "READY" from the listing and replacing it
with an OK (which is what you see in, say, GWBASIC files.)  The first can be
done more easily by the one-liner, the second is not necessary.  GWBASIC will
load the file, declare the READY line as superfluous, throw it out and leave
you with the OK anyway.  QuickBasic uses neither, so it can be deleted by 
any text editor.  The one-liner, incidentally, works on any CBM machine from
PETs to C128.  Load your program, then issue the following sequence:
 
OPEN 129,8,3,"0:YrFileName,s,w":CMD129:LIST
 
then after the drive stops:
 
PRINT#129:CLOSE129
 
Ordinarily only a carriage return is sent at the end of a line, but if you 
open a file to a logical device number greater than 127, a line feed is 
automatically appended. The secondary device subaddress should always be 
greater than 2.
     --Joe P.
 
(PYLKA@PHOENIX.PRINCETON.EDU)



  10.3 Porting BASIC Programs

 EOF Command

> I am not very experienced in programming in BASIC, but have been trying to
> write a program into the CBM BASIC 2.0 that was originally written in
> BASIC for a PC environment.
> 
> Does anyone know how to replace the EOF (End Of File) command in the
> newer BASIC, with commands that the CBM BASIC 2.0 will understand??


It might help if we knew what the EOF is being used for in the 
original program. I think it is generally used at the end of a loop 
or routine that reads a data file. The EOF signals that all of the 
data have been read. If this is your situation, you would have to test
after each piece of data in the data file has been read. The test
might consist of nothing more than a statement like;

	IF ST=64 THEN GOTO 700

ST is the status variable, and will be 64 when the end of a file has
been reached. In this example, you are assumed to have branched out
of the data reading routine when the data has all been read, and gone
to your next routine at line number 700. If the data has not all been 
read yet, execution will pass through this statement and continue in
the data reading routine.

 --

The status variable ST carries the current status for most I/O
operations, including end of file. Here's a program that types a
text file out to the screen (I'm writing this from memory):

	10 input"<clr><ctrl-n>Enter filename";f$
	20 open1,8,2,f$
	30 if(st=0)thenget#1,a$:printa$;:goto30
	40 close1:print

ST equals zero whenever there is no I/O problem and non-zero when
there is. Unfortunately, this program can be tripped up when you
turn on another serial device while the program is running, because
this too will affect ST. ST is supposed to equal 1 at EOF, but this
is unreliable (I have also seen it = 66, although I can't rule out
other devices interfering).

If you are interested in using an ML approach, ST is mirrored at
location $0090 (144 decimal).

 ----

 The command to test for end of file could also be

	IF ST AND 64 = 0 THEN (go back to beginning of loop)
    or
	IF ST AND 64 = 64 THEN (close the file and continue)

 Masking could prevent problems if you're using it in other places.


 Graphics

Worse yet, the commands, especially for graphics, are entirely
different between the two.  You'll need to do some rewriting.

Also, where CBM style BASIC knows keywords and can find them within
a string of nonblank characters, the other MS BASICs require blanks to set
them apart.  Most CBM programs were written in a compressed form to save
on storage.  You'll have to supply the missing blanks. 
In  short, it can be done but there's a lot more work than you expect.

	--Joe Pylka


Finally, a word of warning: If the program uses any kind of graphics
(including re-defined characters) it won't run in QBASIC (on an IBM clone).



  10.4 Tricks on BASIC RAM

   OLD

   Restoring BASIC program on the C128:

	LDY #$01	; 1C01 = start address
	LDA #$1C
	STA ($2D),Y
	JMP $4F4F	; rechain basic lines

  This can be used after 'NEW' command or reset. It is also useful when
  a C64 basic program is BLOADed to C128 and lines need to be rechained.


  It can be done in BASIC as well:

	poke 2050,8	(first line-link)
	10000		(a non-existent linenumber)

 Or, you can poke non-zero values into 2049 and 2050, and then call the
 relinker with SYS 42291 (C64).

 After relinking you can list the program. Note, however, that neither of
 these alternatives set the end-of-basic pointers (VARTAB, ARYTAB, and
 STREND) so you cannot edit or run the program. If you try, the computer will
 usually bomb. To fix, you need to find the real end of program and set these
 pointers, or binary-save (C128) and reload the program first.


   MERGE

 Merge. i.e. load one basic program into another.

:      I have a program that came with my copy of Color64 BBS v7.30 and
:      8.0 that will perform a TRUE merge with BASIC programs.


 Here is a way to load one basic program on top of another. It doesn't 
 actually merge them together: it doesn't replace any lines. It combines
 two programs together.

 You should do this *immediately after* a Cold start (turn the computer off
 and then on again, or SYS 64738 [C-64] or SYS 65341 [C-128]).
----------------------------------------------------------------------------
      COMMODORE 64

	LOAD the first program with no secondary address. Then type this line

	   N=(PEEK(45)+256*PEEK(46))-2:POKE44,N/256:POKE43,N-256*PEEK(46)

	LOAD the second program, with no secondary address. Then type this line

	   POKE43,1:POKE44,8 :CLR

	And the 2 programs will be combined.
-----------------------------------------------------------------------------
      COMMODORE 128

	DLOAD the first program. Then type this line

	   N=PEEK(174)+256*PEEK(175)-2:POKE 46,N/256:POKE 45,N-256*PEEK(46)

	DLOAD the second program. Then type this line

	   POKE 45,1:POKE46,28 :CLR



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

From: dschmoll@nyx10.cs.du.edu (David Schmoll)
Subject: EZ Loader V3.10
Date: 7 Jan 1996 21:27:00 -0700


	ezldr3-1.sfx on the ccgna.uwaterloo.ca

... dschmoll@nyx.net (David Schmoll)



  11. OTHER PROGRAMMING LANGUAGES


 Dan Fandrich (dan@fch.wimsey.bc.ca) maintains an extensive list of all
 Programming languages available for the C64/C128,

   URL  http://www.wimsey.com/~danf/cbm/languages.html

 as well as one for 6502 Cross-Development Languages and Tools

   URL  http://www.wimsey.com/~danf/cbm/cross-development.html


  11.1 High-Level Languages

  11.1.1  FORTH

FORTH is a language well suited for micros like c64. It's
fast and small, and a compiler is relatively easy to implement.


for documents

http://www.dnai.com:80/~jfox/
http://www.paisley.ac.uk/~cis/forth/euroforth.html

for software

via ftp:

ftp.cygnus.com  /pub/forth
taygeta.oc.nps.navy.mil /pub/Forth

via http:

http://src.doc.ic.ac.uk/computing/systems/ibmpc/collections/simtel/msdos/forth/
http://wuarchive.wustl.edu/systems/ibmpc/msdos/forth/


Some Forth sites

Skip Carter's home page on taygeta:
	http://taygeta.oc.nps.navy.mil/skips_home.html

The Forth section of taygeta's ftp sote:
	ftp://taygeta.oc.nps.navy.mil/pub/Forth

Cygnus Forth site:
	ftp://ftp.cygnus.com/pub/forth

   
You guys need to talk to Leigh L. Klotz at:
  
klotz@adoc.xerox.com
  
He wrote two versions (at least) of FORTH. The one that Commodore
 released for the 64 and the one they released for the PLUS/4.
   
I saw a post by him recently that had some facts slightly wrong about
 the release of the c16 and PLUS/4 but he did write both programs and
 should be able to help anyone trying to implement it for ACE.
   
Jack VW


Subject: fig-Forth for 6502 processor
Date: Tue, 12 Sep 1995 23:05:18 -0400

	I have uploaded an electronic edition of the Forth Interest Group
figForth in 6502 assembly language into my shell account, so if anyone is
interested, e-mail me for a copy.  Note that this is the original figForth
for 6502, which was written for an Aim 65, so that there are about 6 Forth
routines that have to be modified to fit this to the Commodore 64.  If
these routines were to call ACE system routines, this might also be a
quick way to get an AceForth up and running (although *not* the way to get
a quick AceForth up and running ;). 

Bruce McFarling, Knoxville
brmcf@utkux1.utk.edu



There is a program called White Lightning (Forth language) that had
multitasking.  I know you could run quite a few task but after the third one
it really slows down.  I don't remember what type of multitasking it had but I 
had very few crashes. 


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

  11.1.2  C


From: Steve Rohatynsky <rohatyns@freenet.mb.ca>
Subject: Re: C
Date: Tue, 12 Sep 1995 03:04:49 -0500



I know of about 4 'C' Compilers for the 64/128...

PRO-LINE made both versions for the 64 and 128  (many say BEST version)
(Better working then picked up the program to re-distribute)

ABACUS also made versions for the 64 and 128 

Theres also 2 versions (I think) for CPM mode on the 128
(haven't seen/used the CPM versions)

I doubt if you could buy them NEW, but I'm sure many used software houses 
would carry at least one of them.


-Steve Rohatynsky (rohatyns@freenet.mb.ca)


From: jamesch@ix.netcom.com (James Chamblin)
Newsgroups: comp.sys.cbm
Subject: Re: ANSI STD C/C++ for the C= 64?
Date: 10 Jan 1996 13:15:24 GMT

>> Where I can find an ANSI STD C, C++
>> compiler for the C64?  I am interested in a full implementation
>> of the ANSI C standard.  I would be interested in FREEWARE,
>> SHAREWARE or anything in the public domain.

>paul.fisher@bbs.wline.se wrote:

>> I just received Power C from Spinnaker (bought from CMD) and was really
>> surprised, I didn't expect much for $14 or from the 64 at that, As far as
>> how ANSI C compatible it is I'm not (yet) qualified to answer but it seems
>> to be very usable and the 128 version is way better (package includes both
>> versions)
>>
>> Paul
>
>None of the C compilers for the C-64 were ANSI-compatible (as far as I
>know, all were written before the ANSI spec came out). Power C and Super C
>were the main ones, and both of these followed the K&R standards used
>prior to ANSI.
>
>
>Doug Cotton
>E-mail: doug.cotton@the-spa.com


There is a PD beta version of an ANSI C compiler.  Don't remeber the 
name, but it exists at ccnga.uwaterloo.ca site.  I also remember it had 
problems, so it might be worth it to just learn the K&R standard and 
use one of the existing C64 compilers.


From: williams@UTKUX1.utk.edu (Myles Williams)
Subject: Re: ANSI STD C/C++ for the C= 64?
Date: 19 Jan 1996 05:33:36 GMT

In article <4dbfcg$i2t@news.xs4all.nl> stijnw@xs4all.nl (Stijn Wolters) writes:
   >You'll be looking for a while.  There is noe, AFAIK.
   I think I have a C compiler that is pretty conform the ANSI standard,
   however I have some problems with the compiler. If it is possible to
   get the compiler working good I'll let you know.

I think it would be helpful to mention that, just last night, I built
myself a version of gcc (GNU C compiler) to cross-compile from a Linux
system to the Motorola 6811.  The 6811 is an 8 and 16-bit processor
used for electronic control.

Since both 6811 and 6502 are based on the Motorola 6800, almost every 6502
instruction is included in its assembly language, in one form or another.

You know how GEOS uses zero-page pseudo-registers for 16-bit work?
GCC has no problem doing that, and in fact the 6811 port takes
advantage of it.

I think a C64 port of GCC would be a worthwhile and feasible project,
for someone else.  All the 6811 machine-specific files are at
ftp://nyquist.ee.ualberta.com/pub/motorola/68hc11/gcc/


From an Altavista search I got http://www.dcs.ed.ac.uk/~axc/FLOOR1/oric.html

--
Myles Williams			"When you see me again, it won't be me."
http://funnelweb.utcc.utk.edu/~williams/ : Free software, Emacs HTML mode,
					 : U.S. government, Censorship


From: Bruce McFarling <brmcf@utkux.utk.edu>
Subject: Re: ANSI STD C/C++ for the C= 64?
Date: Thu, 25 Jan 1996 11:56:26 -0500


> I definitely  will be looking up the book  'Portable C' - any more info 
> on how to identify it ...

  Rabinowitz & Schaap, Portable C, 1990, Prentice Hall.  LC# QA76.73.C15R33.


Bruce McFarling, Knoxville
brmcf@utkux.utk.edu


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

  11.2 Machine Language Programs

  11.2.1 Machine Language Monitors

 In all modes, X64 provides a built-in ML Monitor for disassembling and
 modifying your programs.

 The C128 -- and thus also X128 -- has a built in ML Monitor. To enter it,
 type MONITOR, or on the real C128, alternatively hold down the RUN/STOP key
 while reseting.

 Both C64 and VIC-20 lack a standard monitor, but they each have several
 loadable monitors to pick one you like. Features include up and down scrolling
 and disassembling, sprite dump, transfer, relinking, etc, ...
 Some C64 monitors: wizmon, edmon
 Other C64 memory tools: manipulator

 PET machines with BASIC 2.0 or 4.0 have built-in monitor as well. Various
 loadable monitors use its extension vector to hook into the ROM monitor.
 MICROMON is the best-known one, and it comes in two modules even which
 internally use again a similar extension vector.
 To enter the monitor, issue a "POKE 2,0:SYS 2". This will set the CPU on 
 a BRK opcode, thus entering the monitor.
 On a real PET you can also use the diagnostic sense input to enter ML
 monitor after RESET.


  11.2.2 Assemblers

ACE assembler.
Alternatively, the ACE-128/64 assembler is available for free and can handle
arbitrarily large assembly jobs, depending on the amount of (expanded)
memory you have.  I have a 4600-line program that it slices through like
butter on an unexpanded C128, but I suspect that with my 16.75 Megs of RAM,
I could assemble files that are several hundreds of thousands of lines long
with no problems, except that I would likely exceed the 64K object-code size
limit.  However, the ACE assembler is still under development and thus
doesn't have any exotic features like macros, conditional assembly, or even
include files.  Also, you have to find your own text editor for use on the
64 (I use ZED-128).


Buddy (aka PAL).
It can assemble any size of source direct from a drive and output to memory
or a drive.

I'm very happy with it in general. One of my C64 projects that gets
re-assembled a lot is somewhere around 100K (about 4 or 5K of object code). It
assembles in only a couple of minutes (to a Ramlink). I keep the source in 5
different subfiles so that I can modify and re-save without using up too much
drive space and so they'll each work better with editors.

Buddy has enough features to please anybody (including macros, conditional
assembly, long labels, temporary labels, etc.) and no anoying habits like
insisting on 1 space only between fields for example.

--
I would recommend Buddy 128 as the de facto assembler. It has all the goodies
a serious hacker could ever want.

---

I routinely use the Buddy-128 assembler to compile an 11,700-line assembly
program.  Of course, the program is broken up into a number of "include"
files.  It's a pretty decent assembler and can be bought from CMD (including
both C128 and C64 versions).

Keep on Hackin'!

-Craig Bruce	csbruce@ccnga.uwaterloo.ca

---

How about Byron Montgomerie's SAL, which he based heavily on PAL?  It's 
pretty fast and does most of what PAL can do, including INCLuding other 
parts of the source code, extensive label/operator manipulation, and a 
lot of goodies a good assembler should do (assemble to memory or disk, 
use the BASIC editor and redefinable function keys, bi-directional 
scrolling when LISTing).  And it's under 7K, with a 46K documentation 
file (which is very thorough), and best of all, it's free, available from 
ccnga.uwaterloo.ca (/pub/cbm/programming/sal.sda).  My only complaint 
about it is that it disables the JiffyDos wedge. :(  Were it not for 
that, I'd never have taken a second look at other assemblers; I've looked 
at most every other one available from the major ftp sites, and I find 

Turbo Assembler to be the best, primarily because of the editor (you 
don't need the JiffyDos wedge, and the wedge doesn't always work properly 
on other assemblers that use the BASIC editor).

---

CBM 1982 resident assembler (for C64).
 It assembles to and from a drive as well. The
only thing I don't like is that is you try to do a non-RAM load it considers it
an error, and since there's not a lot of space in the C64 I tend to put code
behind BASIC and the Kernal, etc. It has a lot of normal programming features
except doesn't support local labels. All in all though, an excellent assembler!

---
call CMD and get a copy of Buddy.
AS6502 for PC's is excellent and amazingly quick, but it doesn't let me

LABEL1   8000 LDA #$09
...
         9000 LDA #<LABEL1  ; 00
         9002 STA $0318
         9005 LDA #>LABEL1  ; 80
         9007 STA $0319

Lines 9000 and 9005 are invalid in AS6502.  Thus, it gets bigs points
off.

Patrick Fleming                           (wiz@apple.com)   Apple Computer


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

From: cdoty@aloha.net (Charles Doty)
Subject: LADS


lads assembler.
I remeber saveing a file then placing the name in the upper left hand corner
and typing sys 11000, but what format is the source file in. I got it to no
longer complain about the start address with the *=$c000
but it won't put my code in memory.

--

From: MagerValp@Goth.Org
Subject: macrofire, a really nice assembler

macrofire is a fast macro-assembler for the c64, with a nice
built-in editor and monitor... try it if you can find it.


  Per Olofsson    MagerValp@Goth.Org     http://www.cling.gu.se/~cl3polof/
--

Merlin.
First, it is a commercial program. The author is Glen Bredon, who might still
be around on GEnie or BIX or CS, and the publisher was

MERLIN is excellent for the 128 especially. But it is commercial.
It is published by Roger Wagner Publishing,

	Roger Wagner Publishing, Inc
	10761 Woodside Avenue, Suite E
	Santee, CA 92071
	619-562-3670

Merlin can handle an
8000 line file, although maybe not all at once.  For one thing, it
can assemble directly to disk.  There is also a pseudo-opcode "PUT"
which essentially inserts a text file into your code, so that you
can in essence assemble parts of the code at a time, without having
to store all the code (and comments) in memory.  But, neatest of all,
Merlin has a linker, so that you could assemble different parts of
the code into individual object files, and link them all together.
Even better, of course, is that you don't have to keep re-assembling
large pieces of code which work fine.

For C128, there is Merlin 128 :).
Even works with FD-2000 with no problem.  I bought
mine here a little over a year ago.  Since I consider this one of
mankind's greatest software achievements, I of course wish it were
available commercially.  Maybe CMD can pick it up.

>Patrick Fleming                           (wiz@apple.com)   Apple Computer



 JCL Assembler and Program Development System  V 3.00
 (C) 1983 JCL Software Ltd.
 (C) 1985 CBM and JCL Software Ltd.

 for Plus/4, C64, C128, C128D

 Provides conditional assembly, disk or memory input and output, object and
 include files. ML instruction set expandable for later processors.
 Max source size in memory: C128: 48K; C64: 30K shared with the symbol table.
 Consists of Editor, Assembler, Monitor, and DOS-Support.

 Better Working Power C & Power Assembler ($14.97 for both)


From: mcalavy@nevada.edu (KEEVY MCALAVY)
Subject: Re: c64 assembler needed
Date: 21 Sep 1995 05:39:47 GMT

Frits Hofsteenge (fwhof@xs1.xs4all.nl) wrote:
: Anyone out there know of a good PD assembler + manual for the C64? And of 
: an ftp-site from where to download it?
: I'm asking this for a friend who isn't on the Net, so please don't expect 
: any C64-expertise from me.

   Sure, the best ones to get are the "TurboAssembler" ones (many hacked 
versions) as they have an integrated editor and compiler and are fast.  
Check the CBM FTP listing, I think a site in *.it has a copy of 
TurboAssembler 5.2 - Sharks Fix.  If your friend has an REU he should get 
one of the versions that supports it....

_______________________________________________________________________________
  -- mcalavy@pioneer.nevada.edu -- all possible disclaimers hereby claimed --




  11.2.3 Reassemblers

 German origin "reass" (C64) generates symbolic assembler source code,
 including tables of labels it created. Output to screen or disk.


  11.2.4 Cross Assemblers and Disassemblers / Reassemblers

 Trans64 (PC) has a simple built in disassembler with possibility to save
 the disassembled file as text file.

  * d65 (Unix)

 Even better alternative may be the d65 by Marko Mkel. It's a 6502
 disassembler (reassembler) that uses a recursive scanning algorithm.
 It detects any data blocks very reliably, and produces a symbolic
 disassembly output.
 Available at least from ftp.funet.fi:/pub/cbm/programming/d65-0.2.0.tar.gz.
 It runs on Unix but should port to PC easily.


  * AS6502 (PC)


  * xa  (Atari ST/Linux) by Andre Fachat
	Distributed under the GNU Public License. C source code and ST binaries
	included.

         Andre Fachat
         email (preferred): a.fachat@physik.tu-chemnitz.de
         WWW:               http://www.tu-chemnitz.de/~fachat/
         snail-mail:        Stadlerstr. 17
                            09126 Chemnitz
                            Germany

  * SMAL (Symbolic Macro Assembly Language)

 The SMAL assembler comes in various versions. It was developed by
 Douglas W. Jones, (jones@cs.uiowa.edu) and his students.

 Available via FTP  on ftp.cs.uiowa.edu in /pub/jones/smal/...
		   and x2ftp.oulu.fi in /pub/cross/.../smal/

   smal6502.p.Z -- pascal source for a version of SMAL developed for
                  the 6502 with help from Roger Marty.

   smal6502.txt.Z -- the user's guide for smal6502.p, in plain text format.

  * DASM




DASM [source,Amiga] ( 1987,1988 Matthew Dillon)
   6502 (and others) cross assembler which generates Intel hex output. Includes source in C. 
   <ftp://ftp.funet.fi/pub/cbm/programming/dasm202.tar.gz> 
   <ftp://ftp.netnet.net/pub/aminet/dev/cross/dasm202.lha> 
   On-line program information is available. 
   <http://www.student.informatik.th-darmstadt.de/~mepk/c64/projects/assembler/dasm2120.zip> 


From: rhialto@mbfys.kun.nl (Olaf Seibert)

DASM, Matt Dillon's assembler does this, and lots more, and it works on
any system that has an ANSI C compiler. You can find it on
ftp.funet.fi:pub/cbm/programming/dasm202.tar.gz. I have been adding
experimental INCBIN and INCDIR directives; if you want to try those
drop me a mail.

Also check out DASM (available from ftp.funet.fi). It supports several
processors besides the 6502 (6303, 68hc11, 68705), has macros,
conditionals, inclusion, etc; everything that a decent assembler should
have.

>I think I can add some limited 65C816 support for the assembler with the
>same file.  Did a little research, but not done.  

I guess adding support for the  65C816 in DASM should not be too
difficult.  I never studied its instruction set precisely though.

>I wish I could find an cross assembler:
>
>written in C.
>source code available

check and check

>syntax like MASM6502.
>macros like masm6502,

Don't know about these. Dasm's macros are a bit different from others
though; it uses {number} to refer to the arguments.

>I have looked at some of the others, but they either don't support macros,
>or the syntax is funny.  I have just enough time to modify some code to

Dasm's syntax is pretty straightforward. I've put in a few hacks so
that it supports a few different styles of doing things. To see an
example of how you can use it look at prlink (also on ftp.funet.fi).

>do structures and 65C816 opcodes, but not enough to recode the entire asm.
>Anyone know anything that might fit?  Any source code for MASM?

One of the dasm examples does structures. One could wrap it in macros
if you wish.

;;;;
;
;       Using an uninitialised segment to create C-like 'struct's.
;       (idea taken from IBM-370 assembler style "dummy segments")

        seg.u   node
        org 0

s_next  ds.b    2       ; a node has a pointer to the next one
s_data  ds.b    2       ; and 2 bytes of data
s_more  ds.b    3       ; and 3 bytes of something more

        seg     code

ptr     equ     42      ; dummy value
        ldy #s_data
        lda (ptr),y     ; get first byte of data

>Jim

-Olaf.
--
___              Copyright 1995 Olaf 'Rhialto' Seibert. All Rights Reserved.
\X/    You are not allowed to read this using any kind of Micro$oft product.



  * "recomment" reassembler (Unix)
	Re-Comment is a database driven reassembler written in PERL language.
	It's included in the VICE Toolkit distribution.

	Re-Comment recognizes some quirks commonly used in C64, C128 and C65
	programs, and also adds specified comments in the code generated.
	Single or two pass operation and HTML generator provided.



From: schonef@asterix.uni-muenster.de (Marc Schonefeld)
Subject: Re: 6510 cross-assembler
Date: 18 Sep 1995 23:31:47 GMT

Roger W Lueck (coolhand@kaiwan009.kaiwan.com) wrote:
: Can anyone suggest the best (or any) 6510 cross-assemblers for the PC
: platform?  And possible where to get the program? 
: Thanks very much.

I'm currently writing one for Windows under MSVC 1.5 C++ , ,
wanna be a beta tester ??

First demo will be out in about 2 month !


Marc Schoenefeld / WWU Muenster 
Email     :    schonef@uni-muenster.de 


From: s4078tot@sun10.vsz.bme.hu (Toth Balint)
Subject: c64asm.zip - Commodore 64 Assembler & DisAssembler on PC
Date: Sat, 14 Oct 1995 22:22:17 GMT

I have uploaded to SimTel, the Coast to Coast Software Repository (tm),
(available by anonymous ftp from the primary mirror site ftp.coast.net
and the secondary mirrors of SimTel):

ftp://ftp.coast.net/SimTel/msdos/crossasm/c64asm.zip

SimTel/msdos/crossasm/
c64asm.zip      Commodore 64 Assembler & DisAssembler on PC

C64ASM is an assembler for Commodore 64's CPU, the MOS 6510. C64ASM
creates files in Commodore 64's machine language, but the assembler
program itself runs on a DOS based PC.  It supports labels, symbolic
constants, math.  expressions, include files and detailed report.
C64DISA is a disassembler but it can create hexa or ASCII dumps, too.
Both programs support the T64 tape file format and (own) MEM file format.

ShareWare.  Uploaded by the author.

Balint Toth
s4078tot@sun10.vsz.bme.hu


From: Alexey A. Sedov <Alexey@sedov-a.msk.ru>
Date: Mon,  2 Oct 95 18:35:59 +0400
Subject: Re: 6502 emulator
Summary: MC6502 emulator as part of the Turbo Dendy IDE


  One year ago I developed a special system (IDE like Borland's IDE,
MC6502 emulator, cross-assembler & "turbo debugger") to create, execute
and debug programs for "Dendy" game computer on IBM PC. My system was written
in Borland Pascal 6.0 (with using objective extension of Pascal & Turbo
Vision library). All my system is too big (40,000 lines of source code,
approximately) to send it. But I can send you some piece of this
system - MC6502 emulator. I have also some Apple II emulators in
source code, but I'm not an author of them, and they are big too
(200K-600K in .zip-form).
  Send me, if You are interested in.

  Sincerely Yours,
        Alexey
  alexey@sedov-a.msk.ru



From: moranec@hal9000.apana.org.au (Gaelyne Moranec)
Subject: hex file translation
Date: 4 Oct 1995 19:05:35 -0500



 CE> I want to use a cross assembler (TASM30) to write machine code for
 CE> the C64. How do I convert the hex file that is output by the
 CE> assembler to a program file that can be loaded and run on the C64?

Rod Gasson was reading over my shoulder and saw your message.  He uses
TASM30 to write code for the C128.  He said he chose TASM because it
was the only cross-assembler that will generate binary files.  The key
is the following command line for assembly:

tasm -65 -b -y progamname

 CE> I am using an RS232 link between my PC and the Commodore (with
 CE> terminal programs running on both ends) over which I

Rod uses 64Net (he has a batch file load it after the assembly) so that
on the Commodore side all he has to do is load the assembled program by
typing "load progname*

That way he doesn't have to copy the file to the CBM and can test then
go back to programming.  When he finishes for the day he then loads the
file and saves it on the Commodore (without running it first).

I have to admit, it's very efficient.

 CE> Any assistance would be greatly appreciated.

This should be just what you need then.  :-)


Gaelyne R. Moranec    moranec@hal9000.apana.org.au
90 Hilliers Rd        gaelyne.moranec@aftrs.edu.au

WWW: http://www.msen.com/~brain/guest/Gaelyne_Moranec/index.html
QWKRR128: http://www.msen.com/~brain/guest/Gaelyne_Moranec/qwkrr1.html
... http://www.msen.com/~brain/guest/Gaelyne_Moranec/favcbm.html 
-=- QWKRR128 V4.33 [R]



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

  12. FILE CONVERSIONS

  Converting files, mainly in D64 format, for other systems is certainly one
  of the most discussed subject on comp.{emulators,sys}.cbm newsgroups.
  Below are brief instructions for the conversions you may need, to help you
  in using X64.


  12.1  Newline and End-Of-File codes


			Newline			EOF

Commodore		CR (ASCII 13)		none

Unix			LF (ASCII 10)		^D (ASCII 4)

MS-DOS, CP/M		CR LF (ASCII 13 10)	^Z (ASCII 26)

VMS			CR LF, CR, or LF	^Z (ASCII 26)
			(ASCII 13 10, 13, 10)

VM/XA			none			none

Apple Macintosh		CR (ASCII 13)		none

Atari ST		CR (ASCII 13)		^Z (ASCII 26)

Amiga			LF (ASCII 10)		^\ (ASCII 28)


  On Unix, an additional control code,  Control-O terminates output.


 Notes:
	LF	LineFeed (ASCII 10).
	CR	Carriage Return (ASCII 13).
	EOF	End-Of-File. Terminates the input flow from terminal.


  12.2  Converting Text Files

When you download a file from a Unix host to a Commodore, the LF
characters are probably being ignored, so it appears to be all one
line.  However if you convert all the $0A bytes to $0D you may find it
is fine.


  * Unix

  tr '\015A-Za-z\301-\332\\\|\[\{\]\}' '\012a-zA-ZA-Z\|\\\{\[\}\]'
 or
  tr '\015A-Za-z\\\|\[\{\]\}' '\012a-zA-Z\|\\\{\[\}\]'


  * Petcat (Unix/Atari ST/DOS)

 This program converts your SEQ files as well as expands tokenized
 C64/128 BASIC programs into 7-bit ASCII text. Unprintable characters
 can be shown as hexadecimal codes in parenthesis, via `-c' option.
 It is also possible to convert programs from ASCII listings into
 tokenized basic v1.0, v2.0, v3.5, v4.0, v7.0, v10.0 or simon's basic
 programs. This program also replaces certain control code names with the
 actual codes.
 Easy to port. Tested on MS-DOS, UNIX and Atari ST.


  * Gnylf  (C64)

From: triad@marvin.df.lth.se (Linus Walleij)
Subject: Re: ASCII TO PETSCII CONVERSION: HOW TO ????
Date: 11 Oct 1995 19:41:35 GMT

In article <milocco-1110950958050001@mac-linac-1.elettra.trieste.it>,
Andrea Milocco <milocco@elettra.trieste.it> wrote:

>I would like to find out a prog in basic for the C64 to convert ASCII text
>to PETSCII.

I made a program called GNYLF V1.1 which converts the following formats:

	1. Microsoft RTF Rich Text Format
	2. PETSCII
	3. IBM-ASCII
	4. UNIX (ISO) ASCII
	5. Screen Codes
	6. Writers Choice (WP)
	7. Mini Office II (WP)
	8. Authors own (KF Metatext) format

80-columns are reformatted to 40-columns and vice versa. Note that this
converter is for text only, so "ASCII-ART" and charts of any kind will
look like rubbish.

Back and forth any way you like. This program will be released on the new
Triad warez disk in a few days. I will also mail it to comp.binaries.cbm
and put it on the Triad FTP. Check this space for announcement in a few!
If you want to be 100% sure to get this tool, then mail me and I'll drop
a copy in uuencoded mail at release date. This goes for all interested
dudes out there.

And of course this is 100% assembler and 100% freeware. (adhere Stallman!)

Linus Walleij aka King Fisher
 triad@df.lth.se        | http://www.df.lth.se/~triad |


From: triad@marvin.df.lth.se (Linus Walleij)
Subject: Re: Help to convert C64 files to MSWorks on IMB PC.


>I have many word processing files for my Commodore 64 that I would like 
>to import to my new PC and use them in Microsoft Works.  I would rather
>not have to re-type them.  Can anyone help with ideas?

You can run my freeware program called "Gnylf V1.1" to convert the
philez to .RTF (Rich Text Format = Stupid u-Soft standard) which can
easily be converted by the built in converter in u-Soft Worx for Windows
or the Standalone converter WPS that comes with the DOS version of
Worx. Mail me if you want a copy by e-mail. BUT: I guess you have to
run a WP that can create pure PETSCII or similar (If you're not using
Mini Office II or Writers' Choice which the converter supports 'cause
they're 'l33+, that is)

Quite a handy program if I'm allowed to say it myzelph.

Linus Walleij...

|         / \         Adress: triad@df.lth.se        |
|        /   \        Realm of software cowboys: http://www.df.lth.se/~triad |



 * CBMASC.EXE (DOS)

 Converts CBM text files to ASCII.


 * CBMText.exe (DOS) (PC64E118.zip)	by Wolfgang Lorentz

 It handles 7 different C64 text formats and also tokenized basic. You can
 download it from http://www.funet.fi/pub/cbm/emulation/pc64/



	GeoWrite Documents


Subject: Re: transferring GEOS files to my PC
Date: Sun, 17 Sep 95 23:47:51 -0500


I hate to dash your hopes, but you cannot use GEOS formatted disks in a PC
clone drive, either.  There is, however, a solution which I have used in
transferring GeoWrite files from my C128 at home to Lotus AmiPro on my '486
at the office.

  (1)  Convert the GeoWrite document to True ASCII using WrongIsWrite 8.1
in GEOS.  You will lose some of the control codes, but the text will remain
essentially the same, requiring very little text formatting on your PC word
processor.

  (2)  Transfer the ASCII files from a CBM-formatted disk to an IBM-formatted
disk using LRR128 (freeware) or Big Blue Reader (commercial ware).

I do this frequently, and it works well for me.
--
John M. Williams    ___   ___/   /      /    ___/    theenforcer@delphi.com



Subject: Re: Converting GeoWrite to text??? Possible???

> >Is it possible to take a GeoWrite document and convert it into a regular
> >text file???  This would be helpful going from GeoCalc -> GeoWrite ->
> >text -> to email...
> 
> I have a similar question.  How about converting a GeoWrite doc to a text
> file and then to ASCII?  I have a friend who has given up his C64 (bless
> his heart, he cannot be saved) for an IBM compatible, and wants to convert
> some large GeoWrite docs.


Go to ccnga.uwaterloo.ca and look under pub/cbm/os/geos.  Get a file called 
wrongiswrite. The version is WrongisWrite7.
It converts from GeoWrite to text or from text to GeoWrite.  Real good program.

Wrongiswrite will convert between PETSCII and ASCII to geowrite 1.0,2.0 and
 2.1 and back.  It will also convert between geoWrite versions and change 
fonts/styles.  He will then need to use Big Blue Reader or similar program to 
put the files on the IBM floppy.  I do it all the time, it's not hard at all.
(It can't be that bad, *I* can do it!  :-)  )

 --

There is a program called GEOS64CE.zip. This program runs on a PC and 
it detects what kind of Commodore Geos file you have brought over and 
converst accordingly C=Geowrite files are converted to ASCII, Geopaint 
and PhotoAlbum files are converted to .pcx. I have not used this program 
personally, but am quoting from a Berkley Software handout that I picked 
up in their office a few years back. Of course the 64/128 Geos files have 
to be put on a MsDos formatted disk, One way to do this is with Big Blue 
Reader, or modem it over  (regular Phone lines or Null modem)

Phil Porth (aka Phone Man) 


From: triad@marvin.df.lth.se (Linus Walleij)
Subject: Re: Converting GeoWrite to text??? Possible???
Date: 1 Mar 1996 13:50:06 GMT

>Is it possible to take a GeoWrite document and convert it into a regular
>text file?

My Gnylfer can read & write most GeoWrite images and writ them as
whatever you want. Try it out:

ftp://ftp.df.lth.se/pub/c64/C64_Tools/


Linus aka KF



From: Alan Jones <alan.jones@qcs.org>
Subject: Re: GEOS Postscript
Date: Thu, 21 Sep 1995 14:13:00 GMT


Someone asked how to get GEOS Postscript output onto a disk file.
Maurice replyed that CMD's Collette Utilites Disk is needed.

GEOPublish is the only software I know of that will generate Postscript
output from a C64/128, and someday I may need to do this.  GeoPublish
only sends the Postscript commands through the RS232C (user) port at up
to 9600 bps.  It would seem to be simple to capture the Postscript data
stream with another computer using a terminal program and a null modem
connection.  I would try capturing with ACEterm, saving to a 1581 disk,
and transferring to MS-DOS format with Little Red Reader (using an REU).
If you have an IBM PC you should be able to use it to receive the file
more directly.  Has anyone actually tried this method?

alan.jones@qcs.org


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


	Pocket Writer Documents


From: hlh@panix.com (Howard Herman)
Subject: Re: Convert Pocket Writer to PET ASCII
Date: 2 Mar 1996 20:51:59 -0500

In article, jpnan@prairienet.org (Jean P Nance) scribed:

>Somebody who only has and uses Pocket Writer would like to 
>submit material to our user group newsletter. Apparently,
>PW has no provision for turning out disk file in any format except
>its own. Is this true? Has anybody ever developed a utility that
>would convert PW files. The Write Stuff conversion can produce
>something readable, but it is all in caps and loaded with reverse
>codes. Is there any way to go except to retype the material?
>-- 

oh!  This is one of the easiest of things to solve:

Assuming that a SEQ PETSCII file is what is wanted: 

1) With the file loaded, press Control A

2) In response to the requestor "Switch to SEQ file?"

3) Press Y <CR>

4) Then save the SEQ PETSCII file in the usual way, Comkey S.

    (If true ASCII is wanted, after pressing Comkey S as above,
    Press Control A.  "ASCII" will appear in the upper right screen
    corner, informing the user that the file will be saved as SEQ
    true ASCII.)

If there is concern for saving any particular formatting, then the
alternative is to Install the "commodore.pf" printer file.  This is
done by pressing Comkey I, and responding to the requestor.

Then "printing", by pressing Comkey P (capital P), and replying to
the requestor that you want to Print To Disk.

Alternatively, I have found that most publishers want text in
"spillable" format, so the editor can configure things to his/her liking.

In other words:  No CR's within paragraphs, and 2 CR's separating
paragraphs.  (And, in the case of true ASCII, two sets of CR/LF's,)

To accomplish this, the user should use Pocket Writer in the
usual (TEXT, not SEQ format) way.  Then when it comes time to save:

1) Hit the clear/home key twice, to get to top of article.

2)  Press F5 to open the Formatting screen.

3)  Cursor to (or click mouse on) "Right Margin" option.

4)  Change its setting to 9999 (maximum line length).
    (each paragraph will now be on one long line.)

5) Change to SEQ file and Save, as described above, as either PETSCII
   or true ASCII.
 
There really is very little in word processing that Pocket Writer
is not capable of doing.


|  Howard Herman and Associates                 Voice: (212) 532-1485
|  72560.3467@compuserve.com   hlh@panix.com   aa349@cleveland.Freenet.Edu



From: jfh@snet.net (John Halloran)
Subject: Re: Convert Pocket Writer to PET ASCII
Date: Mon, 04 Mar 1996 07:58:21 -0500

In article <4h9s57$sr5@vixen.cso.uiuc.edu>,
jpnan@prairienet.org (Jean P Nance) wrote:

>Somebody who only has and uses Pocket Writer would like to 
>submit material to our user group newsletter. Apparently,
>PW has no provision for turning out disk file in any format except
>its own. Is this true? 

No, its not true. Pocket Writer allows you to save text as well as
in its own format.

The keypress sequence <CTRL>a toggles the filetype of the text
in memory between the two file types. When "SEQ" appears on the
command line, a file saved will be written to disk as a sequential
file.


	Other


From: jamesch@popd.ix.netcom.com (ChrisC)
Subject: Re: Converting C= Word Processing Files to MS-DOS text files
Date: Tue, 12 Mar 96 03:09:52 GMT


In article <4i2idl$o8d@newsbf02.news.aol.com>, ricky021@aol.com (Ricky021) wrote:
>I used a word processing program called OmniWriter64, and used it to make
>*alot* of documents.  (This was all before GEOS even came out). I was able
>to transfer the documents to my PC's hard drive, but now of course I need
>to convert them into a PC readable format.  I read the other post about
>converting GeoWrite documents and it seems _that_ is possible.  Anyone
>know about OmniWriter64? There is some info in the manual about the
>document file formats, if that would help, let me know.
>Thanks for any help!!
> 
>Rich

I found a program called C64Term which is a Color 64 term program for the IBM. 
 Included is a program called CBM2ASCII which converts Commodore PETSCII to 
standard ASCII.  That program should work unless the info is stored in screen 
code format.  Usually there is a command in the word processor to save in SEQ 
PETSCII format.  I've never used OmniWriter64 so I don't know how you would do 
that.  There probably is a screen code to ASCII converter program too 
somewhere.



------------------------------------------------------------
--    jamesch@ix.netcom.com     --      Xdr12@aol.com     --



From: koskphon@inet.uni-c.dk (George Brock-Nannestad)
Subject: Re: Converting C= Word Processing Files to MS-DOS text files
Date: 12 Mar 1996 15:48:24 GMT


Ricky021 (ricky021@aol.com) wrote:
: I used a word processing program called OmniWriter64, and used it to make
: *alot* of documents.  (This was all before GEOS even came out). I was able
: to transfer the documents to my PC's hard drive, but now of course I need
: to convert them into a PC readable format.  I read the other post about
: converting GeoWrite documents and it seems _that_ is possible.  Anyone
: know about OmniWriter64? There is some info in the manual about the
: document file formats, if that would help, let me know.
: Thanks for any help!!
:  
: Rich
the C64 emulator PC64 v1.18 contains such a program, but whether it supports
the WP program you mentioned I do not know. The shareware version
of PC64 can be downloaded from a number of different sites, among them
 frodo.hiof.no

-Laust


From: gwesp@cosy.sbg.ac.at (Gerhard Wesp)
Subject: Re: Converting C= Word Processing Files to MS-DOS text files


>to transfer the documents to my PC's hard drive, but now of course I need
>to convert them into a PC readable format.

 Have a look at 'tr' or 'recode' of the GNU textutils (e.g. in
ftp.univie.ac.at:/packages/gnu) (Don't know however if those are
available for MS-DOS...). I have successfully used 'tr' to convert a bunch
of MasterText (also some old C64 text processor) documents to ASCII.

 I suspect that your C64 text processor uses
a very simple encoding scheme, so it should be easy to convert.


-Gerhard



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


  12.3 Converting CBM Archives


  12.3.1  Commodore 64/128 Compression Software


UU-Xfer 64/128

   An all-purpose UU-decoder/encoder for the 64/128. Necessary for use with files on
   CFN that might be encoded. Graphics on archives usually use this encoding.
   Documentation is included. Runs on all Commodore 64/128 computers.

    o UU-Xfer 2.7K bytes 
    o UU-Xfer.Docs 2.7K bytes 



ZipCode 64 
   This unpacking program will allow you to unzip any program that may require it on
   CFN and any other archive. Read and print the 'ZipCode.Readme' and
   '1_Zip.Readme' files before proceeding for instruction how to properly use this
   program. Runs on all Commodore 64/128 computers.
    o ZipCode 11K bytes 
    o ZipCode.Readme 400 bytes 
    o 1_Zip.Readme 2K bytes 
    o 1_Zip 37K bytes 
    o 2_Zip 41K bytes 
    o 3_Zip 36K bytes 
    o 4_Zip 39K bytes 
    o Zip Collection 15K bytes 


PKUnZip64 V1.01 
   Packing and unpacking program for the 64/128 system. Read and print the
   'PKUnZip.Readme' file for instructions on installation and use of this program.

    o PKUnZip64.Readme.sfx 5.5K bytes 
    o PKUnZip64.sfx 12K bytes 

Decomp 64/128 
   A series of 5 decompression and conversion programs. Read and print the
   'Decomp.txt' file for instructions.

    o Decomp.txt 966 bytes 
    o Decomp.lzh 30K bytes 
    o Decomp2.lzh 21K bytes 

LZHTOSFX Conversion Program. 
   A program necessary for converting some archives from the MS-DOS style of
   encoding (.lzh) to the self-dissolving archives (.sfx) of the 64/128 series of
   computers. Read and print 'LZHTOSFX.Readme' file for instructions.

    o LZHTOSFX.Readme 3.0K bytes 
    o LZHTOSFX.sfx bytes

C64S_ARC V1.1B 
   Necessary for converting .d64 (disk) and .t64 (tape) files over to C64 files for use of
   the Commodore 64/128. Use the 'ZipCode' program to unpack and run for on-line
   instructions. Most game archives use these filetypes for storage and conversion is
   impossible without this program.

    o C64S_arc.zip 72K bytes


Trans64 (C64 Emulation Converter) 
   Actually a program for PCs, it allows the PC user to run many .d64 (disk)
   and .t64 (tape) programs, emulating a C64. For those former C64 owners who
   are feeling nostalgic over the old 64s, they can now relive the magic.
   Use PKZip to expand.



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

  12.3.2  Lynx Archives



[ dissolving Lynxes on PC64 ]
 make sure LYNX was set to drive 8 for reading, drive 9 for writing...


 some unpacked .lnx'es on my harddrive, and I just
created a new .d64 empty disk with C64S, then (from DOS) copied it 6-7 times
so I had lots (right.. :) of free disks on my hard drive. Then from C64s
imported the .lnx files into the disks (keeping on filling until I got an
error (disk full) on each).
After that, just started Lynx (from a tape image, but that's, ahem, irrelevant)
and dissolved all files in a row.



From: triad@marvin.df.lth.se (Linus Walleij)
Subject: Re: What to do with ZipCode and Lynx archives?!
Date: 23 Jan 1996 10:48:22 GMT


> The Lynx/unLynx utility is also done
> - it will be included in the next release. (Star Commander)


There exists a unlynx program for DOS already:

ftp://ftp.funet.fi/pub/cbm/c64/Archivers/unlynx.zip

(I'm not 100% sure about this URL, I'm just writing it down from my
head, so go for something similar if it doesn't match xactly...)

Linus aka KF


From: Jacob Gorny <gornyja@whitman.edu>
Subject: Re: Decompressing LYNX files - How ??
Date: 3 Dec 1995 03:17:05 GMT


>> Does anyone have a MS-DOS or C64 utility to decompress LYNX files ?

Omega-Q works very well generally. It works better on PC64, where you can 
define multiple drives, although c64s can run it... If you can't find it 
anywhere, e-mail me... Ultimate lynx is the other utility you could use, 
but I haven't found a good version of it yet...

Jacob Gorny
gornyja@whitman.edu


From: dan@fch.wimsey.bc.ca (Dan Fandrich)
Subject: Re: Lynx compression?
Date: Wed, 28 Feb 1996 02:20:45 -0800

In article <Pine.SOL.3.91.960223012426.9454B-100000@utkux4.utcc.utk.edu>
brmcf@utkux.utk.edu writes:
>        So lynx 'compression' is the C64 equivalent of tar format: just a 
>way to bundle files together.  Leading to two questions:
>        What is the lynx file format?

Take a look at the source code to fvcbm (there should be a pointer to it at
<URL:http://vanbc.wimsey.com/~danf/software/> (email me if you want to beta-
test a new version of fvcbm).  That should show you the directory format at
the start of the Lynx file.

>        What would be a good way to compress a lynx file so that it could 
>be decompressed quickly?

The big advantage to Lynx is that the file format is designed so that when
it is stored normally on disk, the files each start on new sectors (i.e.
the "blocking factor" is 254 bytes).  This means to to Un-Lynx an archive
new directory entries need to be written and a few track & sector links
changed.  This can be done on the 1541's processor very, very quickly leaving
the data in place on disk.  You don't need twice the disk space to unarchive,
either.  Compressing the archive would eliminate this feature and negate the
value in using Lynx.

>>> Dan
-- 
dan@fch.wimsey.bc.ca / MIME email ok / finger danf@vanbc.wimsey.com for pgp key

From: e9325492@stud1.tuwien.ac.at (Predi)
Subject: Answer to decoding LNX files
Date: 27 Feb 1996 23:49:07 GMT

HERE IS THE ULTIMATE SOLUTION FOR DECODING .LNX FILES
  ( btw, does anybody need help except me ? )

1. download the file called "lynx17.sfx" from 
     ftp.funet.fi/pub/cbm/archiving/c64/
2. start c64s.
3. import lynx17.sfx
   load it. follow the instructions. lynx will self-extract.
   start the extracted file.
4. press F9. press ALT-D.
   create a new disk, then import the lnx file you want to decode
   into it.
   set this disk as default.
5. return to the lynx program by hitting ESC.
   select 'DISSOLVE' from the menu to decode your file.

after all, it wasn't THAT hard ....



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



From: schepers@dcs1.uwaterloo.ca (Peter Schepers)
Subject: Re: BADLANDS from SHARKBITE doesn't work - Please HELP !!!!
Date: Thu, 16 Nov 1995 16:02:44 GMT


 displays the message "Use Lynx to dissolve this file".

>What it means is that the file is a Lynx archive. Lynx doesn't store the files
>as disk-images(like D64) but merges a bunch of files into one big file.
>
>There are several unLynx'ers available for the C64. Don't know if anybody
>did a ms-dos version.

Sure, they have been ported/compiled on the DOS end. The Star Commander 
will have it as an external program (like StarZip), there is a separate 
program called UNLYNX.ZIP, and I also have it coded into my utility 
64COPY (along with ZipCode/UnZipCode).

All of these are available from RUSH.UWATERLOO.CA under /UTILS


-----------------------------------------------------------------------------
 Peter Schepers,                 | 
 Dept. of Computing Services,    |   The opinions expressed in the above
 University of Waterloo,         |   rant are those of the poster, and not
 Waterloo, Ontario, Canada.      |   necessarily shared by anybody else on
 1-519-885-1211 ext 2456         |   this planet (or employer).



From: msalomon@ccnet.com
Subject: -* CV64: convert LNX/ZIP to T64/D64 *-
Date: 25 Feb 1996 18:47:58 -0800

CV64 v1.0 converts C64 programs, LNXs
and zip archives, with long filenames
in LHAs, to ZIPs under DOS.  Requires
LHA,MAKETAPE,UNLYNX,ZIP2DISK,PKZIP.

This program (which I wrote) is especially useful for converting files 
found on SharkBite Online to T64s and D64s under DOS!

It can be found at:
  ftp://ftp.ccnet.com/users/msalomon/c64/cv64.zip

The utilities that it requires (with the exception of PKZIP) can be found 
in the same directory:
  lha213.exe, maketape.zip, unlynx.zip, zip2disk.zip

Complete documentation is included.

- Evan


From: sta@ludens.elte.hu
Subject: Re: .LNX -> .D64 utility?
Date: 26 Feb 96 08:34:27 +0200

>     Are there any utilities to convert .LNX files directly to
> a .D64 format?  And if not, where can I find docs on the .LNX
> file format?
> 
>     I've looked for both, but haven't found anything.  I would
> appreciate it if someone could send me either of these, or at
> least point me in the right direction.
> 
> Thanks,
> Larry

Hi Larry, The Star Commander, Version 0.71 beta will come out next
Monday with a Lynx/unLynx program that can do the following:

- lynx multiple DOS files into a Lynx archive
- lynx the contents of a disk image into a Lynx archive
- list the contents of a Lynx archive (optionally with creator, too)
- unlynx a Lynx archive into multiple DOS files
- unlynx a Lynx archive into a disk image

The program ALWAYS keeps the original names of the files.

Also ZipCoder included.


Joe Forster/STA
sta@ludens.elte.hu

From: schepers@dcs1.uwaterloo.ca (Peter Schepers)
Subject: Re: .LNX -> .D64 utility?
Date: Mon, 26 Feb 1996 13:11:27 GMT

>>  Are there any utilities to convert .LNX files directly to a .D64 format?

>There aren't any tools that I know of that convert directly into a .D64 
>image but it is very easy to do from inside the emulator. I always copy 
>my .LNX files into a .D64 file and then simply load "Ultimate Lynx" from 
>within C64S and unlynx from the .D64 file like I would a normal c64, it 
>works very well.


64COPY has the ability to convert the contents of LNX's
to any format you want. If the LNX contains ZipCode files,
these will be converted automatically to D64's.

You don't have to do anything with the emulators themselves,
just use this DOS utility.

64COPY has a Norton Commander-ish feel (its not exactly the
same). It treats D64/T64/LNX/P00 as subdirectories,
and by using the F11 (Convert) Fkey, you can convert files
inside any of these image formats to most others.

If you want to try out this program, it is available on my
FTP site at RUSH.UWATERLOO.CA under /UTILS as 64cpy2xx.zip,
where xx is the presently available version.

-----------------------------------------------------------------------------
 Peter Schepers,                 | 
 Dept. of Computing Services,    |   The opinions expressed in the above
 University of Waterloo,         |   rant are those of the poster, and not
 Waterloo, Ontario, Canada.      |   necessarily shared by anybody else on
 1-519-885-1211 ext 2456         |   this planet (or employer).



From: diku2471@diku.dk (ASGER ALSTRUP NIELSEN)
Subject: Re: Proposal: Linux PC as file server for C64
Date: 23 Feb 1996 01:27:06 GMT

s_wzimme@panther.rz.uni-ulm.de (Walter Zimmer) writes:

> I got the problem to transfer the programs to my 'real' C64. I read about
> the things where you can service a 1541 on an MS-DOS PC, but I didn't find
> anything for linux. I had the idea to just connect the C64 to the Linux PC
> and let the PC serve the files.

>Example:
>To load from the floppy: Load "name",8
>To load from the PC:     Load "name",9 and it comes from the harddisk
>Then you could copy disks etc...

>Any ideas and people willing to participate in programming such a server ?


It more or less has been done. Check out 

   http://ftp.funet.fi/pub/cbm/transfer/Linux/

It also works for MS-DOS and Amigas.

Asger Alstrup



  12.3.3  Convert Commodore ZIPCODE format to .D64

	If you have

	1!whatever
	2!whatever
	3!whatever
	4!whatever

then ignore the ?!'s and use 'zip2d64 whatever' or something...

	ZIP2D64 whatever file.d64 

 This would write a .D64 file named "FILE.D64" with the contents of
the 4 ZIPPED files you used
(do NOT type the 1! etc crap! Just name and extension) 

Say, to decode File (i.e. 1!file.oce, 
2!file.oce etc.) you have to type ZIP2D64 FILE.OCE (that is, all of the name 
AFTER the !) FILE.D64


ftp://frodo.hiof.no/pub/c64/utils/zip2d64.zip
ftp://lennon.engr.wisc.edu/pub/c64/utils/zip2d64.zip

  T64/D64 conversion utilities:
	d64utils.zip, d64util.zip, and 64uti5.zip.


  12.3.4  Dissolving big ZipCode files

Usually this will not be any problem.
ZipCode will ask you to put in the disk with 4!xxxx on it. In fact you could
putALL the files on seperate disk and Zipcode would ask for each part.

What you do is put the 4! file on a separate disk, and when it says it can't
find it, just put the disk in that has it. The disk that is being written too
will be fine (it doesn't have to be '71/'81 unless it was zipped with that version and specifically says so).  This is just a case of the archive being
bigger than the actual data.


From: Pontus Berg <Bacchus@FairLight.COM>

> These four files are representing a whole diskside. I would appreciate
> any detailed information about the format and the pack algorithm of ZIPCODE.

The are RLE packed parts of the disk. Would you want sources in C/Pascal on
how to pack/depack them? (I'm not sure I have the lot, but Marko Mkel
did work on a C version, that I knwo for sure!)


[  o/  PBG@HK.Mobitel.Telia.SE   Bacchus@FairLight.COM         ]
[ /7        Fido: 2:201/411.71   AmigaNet: 39:164/1.71         ]





  12.3.5  .D64 -> Zipcode

disk2zip converts D64 to C64 Zipcode file.

Unt64 and Und64 will convert .t64 and .d64 files into normal C64 PRG files.
Available on Aminet/pub/misc/emu,  and frodo.hiof.no.

Trans64 (DOS) will extract file from a d64 or t64 image.  The file must comply
with the 8.3 FAT limitation, unless you can run it under OS/2 on HPFS.  You 
are given the opportunity to rename the file.

  Converters etc. WWW page:
	http://www.cfn.cs.dal.ca/Services/PDA/commodore.html


  For Infocom games, there is a program that lets you take .d64 and translate
  it into a .dat file that any z-code interpreter can read. z-code is the
  format for all infocom text adventures, and interpreters are available for
  macs (and most platforms). the files needed can be found at 
	ftp://ftp.gmd.de/if-archive/. 



Here is (uuencoded) little program by Rick Kephart for use to dissolve
.d64 files. You need at least one 1571 (or bigger) drive, since the whole
thing won't fit on a 1541. 
It transfers a .d64 file on Drive#9 to a *formatted* disk in Drive#8.

begin 600 d64
M 1PJ' H _B4ZA2)&24Q%3D%-12([3B0Z_@TC,2PH3B0I+%4Y.HM$4Z>0 $(<
M% "?,34L."PQ-3J?,BPX+#(L(B,B %X<'@"!5+(QI#$W.H%3LC"D,C ZC3<P
M.H(Z@@!['"@ @52R,3BD,C0Z@5.R,*0Q.#J--S Z@CJ" )@<,@"!5+(R-:0S
M,#J!4[(PI#$W.HTW,#J".H( P1P\ (%4LC,QI#,U.H%3LC"D,38ZC3<P.H(Z
M@CJ@,3J@,CJ@,34Z@ #C'$8 F2(3(" @(" @(" @(" @(" @(" @(" @$R)4
M+%, ^!Q0 )@Q-2PB53$B.S([,#M4.U,  AU: )XW-#4U !<=9 "8,34L(E4R
M(CLR.S [5#M3 !T=;@".    H@$@QO\@Y/^- !7N*!W0]2#,_Z("(,G_K0 5
M(-+_[C@=T/5,S/\:&AH:&AH:&AH:&AH:&AH:&AH:&AH:&AH:&AH:&AH:&AH:
 
end



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

	ZIP

From: sta@ludens.elte.hu
Subject: Re: SHARKBITE ONLINE - Problems - PANG, Chase HQ II, etc
Date: 20 Nov 95 14:17:11 +0200


SC doesn't support ZipCoded images DIRECTLY but there's a file
called SC_ARC.ZIP in the distribution package which contains a
ZipCoder; it can zip/unzip/test ZipCoded archives and is about
twice as fast as the other ZipCoders.

The big problem is that if I stuff everything you want into the
Commander it won't fit into that 640 KB... :-) So I only implement
the basic file formats inside the main program and implement such
conversions with stand-alone programs. Like e.g. I'm planning to
code a Lynxer and a P00<->T64 utility for the next release. Bye!

Joe Forster/STA
sta@ludens.elte.hu


From: ulrich.steppberger@public.uni-augsburg.de (Il grande Fool)
Subject: SharkBite - EASY solution!!!
Date: Thu, 30 Nov 1995 20:05:48 GMT


Why on earth do you believe Netscape is the only way to get to SharkBite?

It's a FACT that the archives are screwed up when you download them with 
Netscape, and there's NO way to change it! Everyone talking about downloading 
it with the shift key or other stuff is simply wrong and obviousely hasn't 
tried it yet.

Anyway, to the point: If you can't use Lynx for whatever reason, just get NCSA 
MOSAIC!! As crappy as it may be, it has one advantage: The archives can be 
downloaded without being corrupted!


From: h9101322@falbala.wu-wien.ac.at (Guenther Bauer)
Subject: Re: Zip2d64
Date: 16 Jan 1996 21:32:42 GMT


: I need a program which converts zip images (1!*.prg, ...4!*.prg) to d64 
: files for the Amiga... (for use with A64)...



Try ftp.giga.or.at /pub/c64/emulators/msdos/zip2d64.zip 

There are sources included, so it should compile and run on your Amiga as 
well.

BTW, the other way round (d64 to zipcode) will be soon available on my 
site as well.

Cheers
Guenther

From: dan@fch.wimsey.bc.ca (Dan Fandrich)
Subject: Re: Zip2d64
Date: Tue, 16 Jan 1996 00:41:58 -0800

In article <4ddk2r$isp@ranger.interlink.no> paithan@interlink.no writes:
>I need a program which converts zip images (1!*.prg, ...4!*.prg) to d64 
>files for the Amiga... (for use with A64)...

Guenther Bauer just pointed a DOS one out to me, at:
  ftp.giga.or.at:/pub/c64/emulators/msdos/zip2d64.zip

This includes source code for Turbo Pascal which should be pretty easy to
port.  A version in C is supposed to be available somewhere as well.

>>> Dan
-- 
dan@fch.wimsey.bc.ca / MIME email ok / finger danf@vanbc.wimsey.com for pgp key


From: pbeast@stellar.comnet.com (Perry Eidelbus)
Subject: Re: Zip2d64
Date: 21 Jan 1996 09:51:08 GMT

David Cummins (davcum@delphi.com) wrote:
: >I need a UNIX prgm that can change d64 to zipcode in my shell acct...Do 
: >you have anything like that?
: .
: Jeez, guys, why not just get a commie? Life would surely be simpler. :-)
: Dave

Actually, it's much easier with my shell account.  The d64-to-zipcode
program I've compiled on my account takes two seconds to convert a .d64
file to the four zipcode files.  Thus, the only substantial time I spend
converting is in unzipping the files (only a couple of minutes).  Also,
since zipcode packs unallocated sectors, the four files are almost always
less than the full .d64 file, so I save time in downloading.  This whole
process is currently quite a bit faster than spending 10 minutes in
converting each .d64 directly to a 1541 (with Jiffydos'd 1581 and 1541),
sans downloading time. :)


Perry-beast            Political Science major, poet and singer, PC hardware
pbeast@utw.com         tech and a very Beastly Nice Chap (hey, ask Linus!).


.............................................................................


From: Christian.Wolf@Informatik.Uni-Oldenburg.DE (Christian Wolf)

This format 1!xxx 2!xxx 3!xxx 4!xxx is a special pack format of the c64...

Just download at: utopia.hacktic.nl:/pub/c64/Tools/Archivers
Zip-Unzip_II.prg.gz 

With this tool you are able to Unzip the files...


From: mepk@hp67.rbg.informatik.th-darmstadt.de (Christian Janoff)

These are zipcoded files. Decompress them with the zipcode program (for the C64).
If you are on a DOS machine you may try zip2d64.exe which converts the four
files into one .d64 (for C64 emulators).

You'll find zipcode at one of the following sites:
           ftp.funet.fi       - /pub/cbm/c64/archivers
           ftp.inf.bme.hu     - /pub/cbm/c64/utility/disk
           ccnga.uwaterloo.ca - /pub/cbm/archivers

or download it directly from the ftp section of PK's Commodore 64 Page,

	http://www.student.informatik.th-darmstadt.de/~mepk/c64.html


// Christian Janoff                         Technische Hochschule Darmstadt  \\
\\ Email: mepk@rbg.informatik.th-darmstadt.de



From: pladow@cad341.intel.com (Peter LaDow)
Subject: Re: Want games? Get me zip for Unix!
Date: 30 Jan 1996 00:53:37 GMT

In article <c94perei.822670683@news> you write:
>Vance Brasher <vbrasher@aberdeen.geoquest.slb.com> writes:

>>> Most UNIX systems have "zip" or gzip on them. I have never had
>>> problems unzipping/zipping PKZipped files using  the Unix zip/unzip
>>> program.

>I can use gzip, but I didn't think you could make pkzip-compatible zips with 
>that one, since it uses  the extension gz. Can you?

Look on ftp.uu.net in the /pub/archiving/zip directory.  There is a zip
package called unzip-50p1 or something like that.  You will need to compile
it, but I've compiled it on HP-UX, RS6000, Linux, and in DOS without a single
problem.  There is also a zip package.  I use these exclusively in Unix
without any problems.

Pete
pladow@scdt.intel.com

..............................................................................


From: schepers@dcs1.uwaterloo.ca (Peter Schepers)
Subject: Re: What to do with ZipCode and Lynx archives?!
Date: Tue, 23 Jan 1996 17:21:19 GMT


While I also use (and beta test) Star Commander (for the 1541-PC link), my
own program also does UnLynx (and UnZip), but it is built into the
program, and therefore integrated. It allows you to convert from a Lynx
archive to almost any other format (except Lynx and ZipCode). You don't 
have to convert the Lynx to DOS and then to whatever format you want.

The program is called 64COPY, and as of today the latest version is 2.10
(2.11 is undergoing testing now and includes a text viewer, HEX editor). 
Look for the file 64CPY210.ZIP (anything previous to this just isn't good
enough), and if you can't find it, mail me and I will email it to you. 

-----------------------------------------------------------------------------
 Peter Schepers,                 | 
 Dept. of Computing Services,    |   The opinions expressed in the above
 University of Waterloo,         |   rant are those of the poster, and not
 Waterloo, Ontario, Canada.      |   necessarily shared by anybody else on
 1-519-885-1211 ext 2456         |   this planet (or employer).


  12.3.6  * LHA

From: gt6010a@acmex.gatech.edu (Jeremy Ouellette)
Subject: Re: Problems with C64 archives!!
Date: 15 Feb 1996 20:15:41 GMT

Matz Karlsson (t94mk@kna.hk-r.se) wrote:
:    Hello!! :)

: I got a little problem with decompressing 
: C64 archives.

: First, how can I Extract LHA archives containing
:  long filenames, I uses windows95 (MsDos7.0).
:  The files get names like FILE~1.LNX
:  And if more than one file have the same first
:  letters in the name it get overwritten.. :(
:  For example,
:     1!California_Games.Epyx.Side_1 and
:     1!California_Games.Epyx.Side_2
:  Get the same name and get overwritten.

You might want to try WINZIP for Windows '95; it supports long filenames. 
I haven't personally tried it with any LHA archives, but it's worked great
for .GZ, .TAR, .ZIP, etc.

Jeremy Ouellette


Subject: Re: Unpacking .LZH/.LHA files in C64?

: How to uncompress .LHA/.LZH archives in my C64? I've tried LHX64
: unpacker, but I get errors in every file - when I transfer those
: into my PC and unpack, no errors.

It sounds like the archives are LHA version 5.  CS-DOS's LHX only does 
version 1, so I'd guess LHX64 is the same way.  If you can list the 
contents of the archive, it should tell if they are version 1 or 5.

The only utility I've found for unpacking LHAv5 is a CP/M utility called 
PMEXT.COM, which is part of the PMAUTOAE.COM package, available at 
ccnga.
--
The only problem there is the Commodore names.  CP/M cannot handle
file names that do not conform to the DOS naming convention.

SO.....just get the source for LZH, compile it on your UNIX
account....and have fun.  Do not forget to set the compress
switch to -o (old style -LH1-).

> A 128 in CPM mode can dissolve some of them like LH-1, LH-5, IBM .arc,
> and .arj.  (We can't yet disolve PKzip 2.04g (or .gz), Unix Compress
> (.Z), or Mac formats.)



From: Phil Hoff <phoff@ecst.csuchico.edu>
Subject: Re: Decompressor for .LHA?
Date: 16 Feb 1996 16:53:06 GMT

galvarez@cs.ucsd.edu (Guillermo Alvarez) wrote:
>
> 
> I have access to a UNIX machine, but I couldn't find a program to
> decompress the LHA files (running on UNIX or MSDOS, doesn't matter)... 

LHA is the default archiving method on the Amiga. If you have access
to an Amiga, download from 
ftp.wustl.edu/pub/aminet/util/arc/LhA_e138.run
Running this program on the Amiga will de-arc it. The LHA files are 
then de-arced on the Amiga and exported to the PC or whatever. 
CrossDOS makes it easy as pie to read and write PC disks on the Amiga.
Maybe someone else knows how to de-ard .LHA on the C64.



From: ismael@CAM.ORG (Ismael Cordeiro)
Date: 9 Mar 1996 19:10:52 -0500


>    How do you un-compress .LHA files?

You couldn't dissolve them with CS-DOS' LHX or LHX64 because Amiga's LHA
files use the lh5 compression method which is not supported by the two
programs above.

On a C128 you can dissolve them in CP/M mode with PMEXT.COM which can be
found inseide the self-extracting PMA archive PMAUTOAE.COM at
ftp.cam.org/users/ismael/archivers.

On MS-DOS you can dissolve them with LHA.EXE which can be found inside
the self-dissolving LZH archive LHA213.EXE at any SimTel mirror in the
msdos/archiver directory.

Ismael
         | ISMAEL CORDEIRO            | ismael@cam.org             |



Subject: How to un-compress .LHA files?

It's possible the files are corrupt, and because many files failed it's
probable that you downloaded them as ASCII instead of binary.
Re-download them correctly.

 ---
On your DOS box, use LHARC.  The latest version does a decent job on most LHA
and LZH files, and I've successfully extracted CBM and *nix files, though you
should be wary of the long filenames they may contain.

If you can, get a copy of Linux, a good Unix-like OS, that can be installed on
an existing DOS partition.  Then you can use a Unix LHARC app and properly
handle the long filenames.

 ---

There is a 49 blk program on Craig Bruces FTP site called lzhtosfx.sfx in 
the Archivers directory, this should convert the .lzh file to a self 
dissolving .sfx file which only has to be loaded and then run on either a 
64 or 128.

lzhtosfx only works with LZH archives using the lh0 and lh1 storage methods,
not with with LHA archives, which use the lh5 method. As I said the only way
of dissolving LHA archives or LZH archives using the lh5 method on a
Commodore computer is with PMEXT.COM, a CP/M program.

> Maybe someone else knows how to de-ard .LHA on the C64.

LHX64 is a nice little program written by Marko Makela that dissolves .LZH
archives compressed with the LH1 method. It doesn't dissolve Amiga's LHA
archives, which use the LH5 compression method. The only program we have for
dissolving LZH (LH5) and LHA archives is PMEXT.COM in the C128 CP/M mode.

> anyway, it turns the file into an SFX...

In a certain way it does but in memory. Since it's a hack of SFX.ML, LHX64
has the limitations of SFX and if a file in the archive has more than about
43k in its compressed form LHX64 freezes.



  12.3.7  * GNU ZIP


From: "Jeremia J.S" <skynetw@dds.nl>
Subject: Re: Corrupt GZ files on http://www.cling.gu.se/~cl3polof/64games/
Date: Tue, 10 Oct 1995 19:32:33 +0100 (MET)


Do not use WinZip, I always use the DOS mode. Type:  

gzip -dN filename.gz 

(small d for decompression, capital N to retrieve the old and real 
extension name, see gzip -h if you do not believe me)

and it will work properly. GNUzip (gzip) is still the best compression 
program around. Sometimes better than LHA(RC). PKZip really is 
outperformed this way.


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


  12.3.8 Compactors

	Time Crunch 5
	Code Compressor
	ECA Compactor
	Speed-packer 1



From: aa349@cleveland.Freenet.Edu (Howard Herman)
Subject: Re: Self-extracting archive creators
Date: 16 Aug 1995 08:25:40 GMT

John Iannetta, Sysop on the CBMAPP Forum on CompuServe, has authored the
SPYNE self-dissolving C64 file.

A SPYNE file component files can total up to 65535 blocks (about 16
megabytes).  The maximum number of embedded files is 144, and there is
100% protection against duplication of filenames and insufficient room
on the destination disk.

A SPYNE file has the added advantage that it gives the user 2 options
to self-dissolve:  (1) direct onto a 1541 formatted disk on which it
may currently reside (in other words it will make itself disappear from
a 1541 disk in order to make room for its parts), or (2) dissolve its
parts onto any Commodore disk drive, and retain its original SPYNE file.

SPYNE can dissolve files on RAMLink. 


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


  12.3.9  Universal dearchivers

    Suffix  Format
    .arc    ARC
    .ark    Arkive
    .lnx    Lynx
    .sda    Self Dissolving ARC

		http://www.funet.fi/pub/cbm/archiving/cbmconvert-1.1.tar.gz
		ftp://ftp.funet.fi:/pub/cbm/archiving/cbmconvert-1.1.tar.gz

    .???    ???




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

  * 64copy

From: schepers@dcs1.uwaterloo.ca (Peter Schepers)
Subject: 64copy 2.10
Date: Fri, 1 Dec 1995 18:18:01 GMT

Version 2.09 changes from version 2.08 are:
  1. 6510 Disassembler (with extended/illegal opcode support) on 
      SHIFT-F4. It might not be terribly useful, but its there.
  2. BASIC detokenizer on SHIFT-F3, Dump to screen or file.
  3. T64 CheckTape (like CheckDisk for D64's). 
  4. Screen saver with 3 randomly selected savers (Starry night, maze, snake)
  5. Some more configuration options (for Screen Saver delay, DOS 
      CheckDisk command-line)
  6. More changes to the HEX editor.

Version 2.10 of 64COPY is now available for FTP download. Among the
changes from version 2.09 are: 

  1. Almost full support for LNX files. They are treated like a T64,
     so you just hit return to go inside, and copy/convert the contents
     like you would to any other filetype.
  2. Allow conversion of ZipCode files directly from inside a LNX or a 
     T64 file. No more converting them to DOS files first.
  3. Several changes to the Disassembler.
  4. Several changes to the BASIC Detokenizer.
  5. Several changes to the Screen Saver (2 new modules).
  6. One new configuration option "Pause on return from shell".

Thats most for now. Stay tuned for more features. Please read the 
CHANGES.TXT file for more info and specific details on fixes or 
enhancements, and don't forget to mail me with your thoughts on the 
program. I enjoy any and all feedback.

It is available for anonymous FTP download from:

FRODO.HIOF.NO (soon to be under) /pub/c64/utils 
RUSH.UWATERLOO.CA (129.97.108.99), under /UTILS as the file 64CPYxxx.ZIP, 
where xxx is the present version. Do a directory to see what version is 
presently there. If anybody can upload it to other sites, please feel 
free to do so. I don't have access to Frodo (its *way* to slow from 
here), and I don't know of too many other sites that exist now. There are 
also some stand-alone programs there (Zip2d64, d642zip, a C64 assembler, 
etc) which might be of interest.

If you cannot access this site by FTP, email me and I will UUEncode it 
and mail it to you. Please indicate if you must have it split into 
smaller pieces (<64k chunks), or else you will get one large file, and 
your mailer might not be able to handle this.

Don't forget to read the 64COPY.TXT file (not a really good manual, but 
it does contain some helpful info), and please email me regarding your 
feeling about this program, especially if you want an enhancement. I am 
keeping a mailing list of all those who wish to be directly notified of 
new version releases (just in case they miss the posting in 
COMP.EMULATOR.CBM), so if you want your name on the list, let me know!

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

Synopsis:

   64COPY is a conversion program designed to convert D64, T64. X64, 
P00, LNX, ZipCode and Binary files between each other for the various 
C64 emulators that are available. It also handles a variety of DOS 
functions in a manner similar to Norton Commander. It is meant as a 
companion program for Trans64, Star Commander, or any program which 
converts 1541 disks to D64/T64 files.

Some of its more useful features are as follows:
  * Full conversion between D64/X64/T64/P00/LNX
  * Conversion between ZipCode/D64
  * Full DOS directory manipulation/maintenance
  * A powerful D64/X64 CheckDisk routine (it checks virtually everything 
     inside a D/X64 for integrity, errors) with result logging.
  * Also a CheckTape utility.
  * D64/X64 hex/BAM sector editor (with copy/paste)
  * BASIC Detokenizer, Disassembler
  * Built-in screen saver with randomly-selected saver modules.
  * Customizeable color scheme and some user configuration options
  * Uses only 24k when shelled out to DOS.
  * It does a *lot* more, so try it out.

-----------------------------------------------------------------------------
 Peter Schepers,                 | 
 Dept. of Computing Services,    |   The opinions expressed in the above
 University of Waterloo,         |   rant are those of the poster, and not
 Waterloo, Ontario, Canada.      |   necessarily shared by anybody else on
 1-519-885-1211 ext 2456         |   this planet (or employer).


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


  12.4 Emulator Archives

   List Archive Contents

  fvcbm
	ftp://ftp.wimsey.com/pub/msdos/misc/fvcbm20.zip

  fvcbm displays a listing of contents for most CBM and Emulator
  archive types:
	ARC230  (ARC),
	Self-extracting  ARC230  (SDA),
	Lynx,
	CS-DOS  (LZH),
	Self-extracting CS-DOS (SFX),
	PC64  emulator  files  (R/S/U/P00),
	Emulator tape images  (T64),
	Emulator disk images (D64 and X64), including 1541 and 1581 disk types.


  DIR64
  DIR64.EXE works similar to the DOS dir command, but goes into D64 and T64
  files and lists their contents. It also lists the PC64/P00 files with their
  full 16 char name. To get a complete listing of all your C64 programs, type
         dir64 c:\ /s >c64.dir


  12.4.1 Disks

    D64 -> X64 disk		c1541 -cr <new> <IMAGE.D64>
    X64 disk -> D64		dd bs=1 skip=64 if=<old> of=<IMAGE.D64>


c64util.zip (NOT c64utils.zip) in frodo.hiof.no:/pub/c64/emulators contains a pair
of tiny command-line operated programs to (1) list the .d64's directory and
number the files on the disk image, and (2) to export a given file from the
image (that's where you need to know the number given by the first program)
to raw P64 format.  You can then make a .t64 by importing the raw file to
a new tape in c64s10.  This process is, obviously, annoyingly inefficient
and cannot be automated using batch files.


   D64 -> T64


From: msalomon@ccnet.com
Subject: Anyone in need of D642T64 util?
Date: 27 Sep 1995 22:24:24 -0700

     Hey all c64 emu fans out there, I just wrote a simple (but complex of
course) util to convert single files from D64s into T64s, and it'll even
create a loader if it requires a sys address.  It runs in 50-line VGA.
You put the name of the D64 on the commandline, and from there it is all
interactive.  It surely saved me a helluva lot of time converting some
stuff.  Just post here if you're interested, then I could put in on FTP

 --

I uploaded D642T64.ZIP to frodo (frodo.hiof.no).  It should be put in the 
utils directory soon.

- Evan -






	convert .D64 & .t64 files back to CBM 64 files


 The 170K represents the exact,
byte for byte image of a 1541 format disk (including the directory info,
sector links, and all that other housekeeping stuff).  There are three ways
to get the *.D64 files back onto regular Commodore disks:


DT64 by Kevin Brisley runs under DOS and performs many functions on .t64 and
 .d64 images including extracting files from the images back to raw c64 files.
It also copies and moves files between .t64, .d64 and raw images, allows
you to format blank .t64 and .d64 images and more.

DT64C (DOS/UNIX) from the same author includes a number of utilities (source
included) that perform all of the functions of DT64.
C64Neu formats (.P00, .S00) will be supported in the next version.

You can get them from the following sites:

    watson.mbb.sfu.ca:   /c64/emulator/dt64_10.zip   (DOS)
                      or /c64/emulator/dt64c_10.zip  (UNIX w/source)

    wuarchive.wustl.edu:   /pub/MSDOS_UPLOADS/emulators/c64/dt64_10.zip
                        or /pub/MSDOS_UPLOADS/emulators/c64/dt64c_10.zip



   a)  Use the program dfiler to read the d64
file off one disk and write out the 1541 image on another.  This requires
two drives - one large enough to hold the image (has to be bigger than a
1541 to fit), and one 1541 or 1571 to accept the output.  Slow (author
was working on speeding it up), but works.

   b)  Use a program running under Unix to change *.d64 image file into
four Commodore 1!*zip, 2!*zip, 3!*zip, 4!*zip files.  These are NOT the
regular *.zip files, but a C64/C128 specific method of generating a
disk image.  (Broken into four pieces.)  There is a Commodore utility
called ZIPCODE to create/dissolve this format.  This can work with only
one disk drive.

   c)  Use a Unix based program to extract the individual files from the
*.D64 image file.  Then transfer the files as usual.  This is difficult
to do on complicated, multi-file packages.




From: discon@news.dorsai.org (Paul Lieberman)
Subject: Re: HELP! How do I transfer .d64 and .t64 files to a CBM disk?


blistyx (user@portal.dx.net) wrote:
: I have a program that is supposed to work on a C64 to extract 
: D64 images to a disk. I have not used it because it is easier for me to 
: extract the files on my IBM and send them to my C64 while I sleep. :)
: If you want, I'll UUencode a copy and post it to this newsgroup. However, 
: you will need ALOT of disk space. That D64 image file is larger than a 
: single side of a 1541. So you will need MINIMUM, a 1571 drive formatted 
: on both sides for 1328 blocks, or a 1581. One of these two will have to 
: hold the D64 file while its contents are written to the C64. I have been 
: told that this program runs EXTREMELY slow....if you guys are still 

It's slow, but it works.  I happen to have a uuencoded copy in my home 
directory.  It's short, so here it is:

**************************************************************************
*   Paul Lieberman             "From out of the depths of Brooklyn..."   *
*   discon@dorsai.org              --       p.lieberman@genie.geis.com   *
**************************************************************************



From: David Belter <dbelter@delphi.com>

>Where can I get a program to convert .D64 files to run on my Commodore?
 
Ok,  heres the lastest version of my Program for converting .D64 files,
it requires 2 drives (or REU with RamDos and 1 drive) and one of the drives
has to have the ability to hold the .D64 file .ie '71 or '81.
It's still slow but I am working on that problem.  I can't seem to generate the
correct Sector Interleaves for each zone.
 
So here's a program by David Belter <dbelter@delphi.com>
 
begin 644 dfiler0.56
M`0@1"/P#F2*3(CJ>(#,P.#(`/`@&!)DB$1$1$1%33U520T4@1%))5D4_("([
M.HTQ,3<P.E-$LL4H020I`&$("P29(D1%4U0N($12259%/R`B.SJ-,3$W,#I$
M1++%*$$D*0!_"!`$GB`S,#`V+$1$.HO"*#0IL[$T,:>-,3$U,`"M"!H$F2(N
M1#8T($Y!344_("([.HTQ,3<P.D0DLD$D.HM!)+(B(J=$)+(B*B(`SP@D!(O)
M*$0D+#0IL[$B+D0V-"*G1"2R1"2J(BY$-C0B`/<(+@27-38S,S$L,#J7-38S
M,S`L,#J7-38S,CDL,#J7-38S,C@L,``O"3@$GS$R+%-$+#$R+$0D.IX@,CDT
M-BQ31#J+PB@T*;(V,J>9(D9)3$4@3D]4($9/54Y$(CJ0`$8)0@13LC`Z5+(Q
M.IX@,S(U-BQ4+%,`4`E,!(TQ,3@P`'T)5@2-,3$V,#J>(#(Y-#8L1$0ZB\(H
M-"FR-C:G5+)4JC$Z4[(P.HDQ,3$P`(P)8`2>(#,R-38L5"Q3`*<):@2+*%2R
M,S4IKRA3LC$V*:>-,3$U-3J0`+<)=`13LE.J,3J),3$P,`#:"7X$F2)$159)
M0T4B1$0B25,@3D]4(#0Q($12259%(CJ.``D*@P29.IDB34E.551%4SHB.\(H
M-38S,S`I.R)314-/3D13.B([PB@U-C,R.2D`'0J(!)X@,C@W,RQ$1"Q4+%,Z
MC@!*"I($GB`S,S$S+,(H,C$Q*2S"*#(Q-"DL,2PQ-RPQ+#$L,C4T+$$D.IDZ
MC@!7"IP$GB`R.3`Q.HX`````3#D+3%4+3((+3+X+3`H,3+@,3/$,J0"D`B"1
MLR#=O:`!H@`@GPK(J2R=,@N,E`JI`*0#()&S(-V]HO_*()\*J0"=,@M@N0`!
M\`>=,@O(Z-#T8*DRC2P+(-D*H``@`0NB`B#)_Z``N<@$(-+_R-#W(,S_H`@@
M`0NED(4%(!0+8*D/KC@+H`\@NO^I`""]_R#`_ZD"KC@+H`,@NO^I`:(BH`L@
MO?],P/^B#R#)_[DC"_`&(-+_R-#U3,S_J0(@P_^I#R##_R#,_V`C0BU0.C,L
M,`!5,3HS+#`L````````"B";MXXX"R!("R!O"DRL"B!S`"#KMX8#I12%`F"B
M#"#&_Z``(,__F<@$R-#W8""Q_ZEO()/_H`"Y@`L@J/_(P`*0]4RN_P``53D@
MF[>*(+3_J6^%N2"6_R"E_XU_"R"E_XU^"R"E_\D-T/D@J_\XK7X+Z3"H.*U_
M"^DPJI@8:0K*T/N%!&`@F[>*CGX+(&8+K7X+(+3_J6^%N2"6_Z`$(*7_B-#Z
MC>L+H`X@I?^(T/I,D`L`H`!HA?MHA?SF^]`"YORQ^_`%(-+_T/&E_$BE^TA@
M(.P+DPX($1$1$1$1$1$1$1$1$1$1("`@("`@("`@("`@("#$QDE,15(@5C`N
M-38-("`@("`@("`@("`@($)9(,1!5D4@PD5,5$52#2`@("`@("`@("`@1$)%
M3%1%4D!$14Q02$DN0T]-#0T@("`@("!#3TY615)4("HN1#8T($5-54Q!5$]2
M($9)3$53#2`@("`@("`@("`@TL71U<G2Q=,@,B!$4DE615,A$P!@(.P+$Q%4
M4D%#2R`Z("`@G9V=`"";MXJHJ0`@S;T@[`L-4T5#5$]2.B`@()V=G0`@F[>*
MJ*D`3,V]()NWCB4.()NWCB8.()NWCB<.()NWCAL.()NWCAP.()NWCB(.()NW
MCB,.[B,.&*XF#JPE#B#P_ZD`C1T.C2`.C2$.C1\.C20.(,\-(.3_\/B-'@[)
M#=`&(*L-3(L-R130"ZT=#O#B(+D-3#D-R2#0"ZT<#O#3[B0.3'0-(.@-K2$.
M\,6N'0ZM'@Z=*`X@TO_N'0ZM&P[-'0[0KJD@(-+_K1T.S20.T`^I`8T@#JTG
M#LD`T`-,'@T@_PU@K20.S1T.T`6I`8T@#F#.'0ZN'0Z]*`[)(-`#SB0.J10@
MTO]@J0"%U*D2(-+_J2`@TO^IG2#2_ZF2(-+_8,TB#I`+S2,.L`:I`8TA#F"I
M`(TA#O#X(',`((NPA2*$(Z``K1T.D2+(J2B1(LBI#I$B8```````````````
J````````````````````````````````````````````````````````
`
end


From: CyberByte/Chris Gioconda <cyberbyte1@pb.net>
Subject: Re: Converting .d64 to regular format?
Date: Fri, 16 Feb 1996 14:52:33 -0500

> > >> How do you convert .d64 files to normal cbm format?

There are 2 programs I have used that have never failed me.  One is for 
the commie (req: a 1571, and a lotta time :)), that someone gave me a 
while ago on the newsgroup.  It is called "cp", and its pretty cool.  
Another one I got is called a.out, and it converts d64's to 4 ZIP files 
(1!zipfile, 2!zipfile, etc.)  That is for a UNIX shell account.  If you 
want copies of these programs I can send em to ya, I dont believe they 
are anything but PD, but then again I may be wrong...

Chris Gioconda


From: c:\nf\usenet\sign
Subject: Re: .c64 and .d64
Date: 18 Feb 1996 15:29:05 GMT

>   esherman@umich.edu (Erika) writes:
>  Can someone point me in the right direction of a FAW, or give me some 
>  instructions on getting .d64 and .c64 files onto C64 floppies to use w/my 
>  C64 & 1541? thanks!!!

>  erika


There are several ways to convert .D64 files to C=ommodore disks.
1. UNIX convert the .D64 back to ZIPCODE, transfer this to the C=
    and dissolve the ZIPCODE files.
2. DOS - Use either, same as above, or 64COPY to move the binaries
    out of the .D64 image - then transfer them to the C=.
3. C=ommodore - Transfer the .D64 file to either a 1571 or 1581 disk
    and use DFILER to dissolve the image back to a 1541 disk.

Tom

      thoot@neosoft.com   15115 Cabots Landing Houston TX 77084  


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

	Compressed D64 ?

From: jlsuker@uci.edu (Johnathon Suker)
Subject: Re: 64 emulation on mac?
Date: Tue, 22 Nov 1994 10:04:38 -0800


> To convert C64 files to mac, I first have to use a program that converts them
> to ibm dos format, then put the ibm disk in the mac.
> if I could just pop my 64 disks into the mac this would save lots o time.

I am in the process of writing a program for the Mac which does just that.
I will allow you to use standard .d64 image types (that are used on with
both the IBM emulators and the Mac64 emulator) and manipulate them on the
Mac (basically a DT64 program for the Macintosh), however, it will also
convert many of the standard Commodore 64 wordprocessor formats (Easy
Script, Speedscript, PaperClip).

The initial features will be coping files to and from diskimage to the Mac
in both binary and ASCII form ( ASCII form will have the conversions done
automatically).

Future features (implemented after the inital version is being banged on
by interested parties, unless I get real productive) will include direct
copying between images, deleting, and renameing files).

Anyone interested in beta copying or wanting more information can send me
email and I will inform you when it is completed (or if you wish to help
test, when it is in beta).


Johnathon Suker                      University of California, Irvine
Office of the Dean
School of Physical Sciences           jlsuker@uci.edu



  Double-spaced floppies

 For *.D64 files dblespace gives nearly 2:1 compression.
 To make, type:   dblspace /compress a:

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

  12.4.2 Tapes

 * Unix/Atari ST/DOS

    T64 -> X64 disk		c1541 -t <disk> <TAPE.T64>
    (To create the disk, use c1541 -f <disk> 'name,id')


 * DOS

    T64 -> P00			T64toP00.exe (Bundled with pc64.)
				Converts all *.T64 files in a directory
				 to *.P00 files

    prg -> T64			maketape.arj
				maketape.exe converts a *.prg file to *.t64

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

  12.5 Images

  12.5.1 General


 tiff -> jpeg

	tifftopnm kuva.tiff | ppmtotga | cjpeg -quality 75 > kuva.jpg &


 (Amiga) ilbm -> gif

	ilbmtoppm | ppmtogif


 C64 Image formats

	C64Gfx Converter (Amiga/Unix)
	   Converts between GIF, IFF, FFLI and BFLI. Archive contains
	   manpages, full image format documentation, ANSI-C source code,
	   and Amiga binaries.
	   Author: Pasi 'Albert' Ojala  (albert@cs.tut.fi)
	   ftp: ftp.funet.fi:/pub/cbm/c64/graphics/converters/C64Gfx1_4.lha 


   FTP: ftp.funet.fi
	/pub/cbm/c64/graphics/converters
	/pub/cbm/c64/graphics/editors       <---editors  ;)
	/pub/cbm/c64/graphics/viewers       <--- guess what it is  ;)
	/pub/cbm/c64/graphics/pictures/FLI  <---FLI pictures


Commodore 64/128 Viewers Software
*********************************

http://www.cfn.cs.dal.ca/Services/PDA/CommodoreViewers.html

VGif 64 by David Jansen
   A Gif viewing program for the Commodore 64/128 series of computers. Documentation is provided.

    o VGif64.Doc.txt 5.1K bytes 
    o VGif64 3.7K bytes

WetPaint 64/128 
   A simple but useful painting program capable of viewing other graphics as well as its own creations.

    o WetPaint 3.4K bytes 


MacTo64 
   A viewer that converts and view Macintosh Gifs on a Commodore 64/128 system. Documentation
   is provided.

    o MacTo64.Doc.txt 4K bytes 
    o MacTo64.sfx 3.1K bytes 



 Doodle -> gif

"dd2rs", (Unix) written by Keith Pomakis and available
from FTP host "ccnga.uwaterloo.ca" in directory "/pub/cbm/graphics/DD2RS"
in files "dd2rs.c" and "dd2rs.doc".  Note that this is a C program and is
intended to be executed on an Unix machine (or whatever).

The program Converts Commodore-64 Doodle or KoalaPainter files to SUN
rasterfile format.  You will then need to use some standard graphics utility
(like "xv") to convert the SUN rasterfile into GIF or whatever other format
you might want to use.


From: jezzydee@clam.rutgers.edu (Jezebel Rebecca Delilah)
Subject: Re: DOODLE Format Wanted
Date: 4 Nov 1995 00:24:59 -0500


Doodle is a program, not a format, per se. 

Doodle format is simply this:

	A Hi-Res picture, two color per 64 bit block, loaded at 23552

	Or more precise: A Hi-Res color map loaded at 23552 
		 	 A Hi-Res bit map loaded at 24576 to 32768

To view a doodle simply set the banks and VIC chip Hi-Res registers to 
those specs... :)

	jezzydee@clam.rutgers.edu :. 
	

From: schwall@zeus.informatik.uni-bonn.de (Bernhard Schwall)

Subject: Re: Doodle to .pcx (or whatever)


: Does anyone know of software that will convert C64 Doodles to some IBM
:  format - preferably .pcx or .tif, but .gif or .jpg OK.

You could use Trans64 1.22. It can convert Doodle, Koala Painter and a lot
of other hires and multicolor formats to PCX.

You can find it on frodo.hiof.no of ftp.rz.uni-hildesheim.de



  11.5.2 GIF

From: John Iannetta <76703.4244@CompuServe.COM>
Subject: Re: help: any programs convert 64 graphics -> GIF format?
Date: 5 Jul 1995 19:59:03 GMT


> Do any programs exist to convert 64 hi-res graphic screens to GIF format?


 TUGIF.BIN" (C64) (public domain) by John Iannetta <76703.4244@CompuServe.COM>
 is available on CompuServe, or from the author.
 It will convert to the CompuServe GIF format or display,
 the following formats:
	RLE, Doodle! (DD),
	Koala,
	Compressed Doodle! (JJ)
	Compressed Koala (GG),
	and GeoPaint,

 Either interlaced or sequential (non-interlaced) GIF modes  may be selected.
 "TUGIF.BIN" was written for the non-GEOS user. The GeoPaint file must be in
 the converted form that is used when uploading.

 Since the size of a Geopaint file is 640 X 720 pixels (while the C-64 screen
 is 320 X 200), only a portion of the image is displayed and converted. You
 must select the vertical portion; you can scroll horizontally for the full
 width using the CSR RIGHT/LEFT key.

 You may also be interested in "GIFCOM.BIN".  It lets you add a comment
 block to a GIF file, as supported by the 89a GIF standard.  A comment block
 is an ASCII text file; it usually contains a description of the image. To use
 "GIFCOM.BIN", you need a GIF file and a PETSCII text file (max size: 42762)



From: mdaymon@rainbow.rmii.com (Maxwell Daymon)

Subject: Re: possible to format disks c64 on other platforms?

Disk-2-Disk. I'll bet bare bones software has it. I converted hundreds 
upon hundreds of disks with Basic programs and text files with it. It 
even supports a number of conversions.

Doodle and Koala Pad graphics         -> Amiga IFF
Speedscript, and various forms of text -> Amiga ISO Latin-1
and no conversion (binary)

--
+- Maxwell Daymon -+- mdaymon@rmii.com -+




From: Chris Scudder <lscudder@ic.sunysb.edu>
Subject: Re: gif file ?
Date: Fri, 30 Jun 1995 01:40:30 -0400

> if i download a gif file from an ibm apple or other site can i view it
> on my 64 ? ..... i already have a gif file viewer.

Yes you will be able to, if it is less than 165K for the 1541...also, 
what prgm are ya using? I find VGIF 2.1 (Im not sure bout the v. #) and 
GeoGIF are amazingly good for the C64...btw all, how are the I Paint/I 
Port prgms for the 128? They sounded good in the CMD catalog....

-Chris



From: Frederick Barnett <fred8615@delphi.com>
Subject: Re: gif file ?
Date: Sun, 2 Jul 95 21:52:30 -0500
 
>what prgm are ya using? I find VGIF 2.1 (Im not sure bout the v. #) and 
>GeoGIF are amazingly good for the C64...btw all, how are the I Paint/I 
>Port prgms for the 128? They sounded good in the CMD catalog....
 
GeGif?? That only converts GIF files to Geopaint files, and takes out the color
in the process!
 

  12.5.2.x Geos GIF viewer

To convert a GEOPaint to GIF just change the file to KOALA format which 
can be done with any number of converters and then compress the file to 
the gg format and then use a program called gifvert.


IPort, from Living Proof Software, can convert Doodle, Koala, GIF, etc. to the 
IPaint format, and can convert from IPaint to GIF.  The transitive property 
yields Doodle==>GIF.  IPort is commercial software, and requires a 128 (may 
require 64K of video memory or a 128D - I am not sure though).
 
Iport will import Amiga IFF, Koala, GIF, MacPaint, GeoPaint, Basic8,
uncompressed Doodle, and Printshop graphics and convert them to IPaint
format which can then be output to GIF format. It requires a 128 (64kvdc
would be useful,) and is available through Creative Micro Designs for $29.

Iconvert - if I remember correctly - was a commercial program from Free Spirit 
that would convert between the major Commodore formats (I used it mainly for 
GeoPaint to Doodle).  I don't remember it supporting GIF, but it has been a 
number of years, so I could be wrong.  It was also a Commodore program, so we 
could be talking two different programs here.



From: John Williams <theenforcer@delphi.com>
Subject: Re: W: 128 80c GIFF viewer
Date: Wed, 6 Sep 95 23:34:19 -0500

Jezebel Rebecca Delilah <jezzydee@clam.rutgers.edu> writes:
 
>Does anyone know of a C128 Giff Viewer that works in 80 col mode? Or 
>better yet a GIFF to CBM converter?
 
Both are available IF you have the proper hardware and software.  geoGIF is
utility for GEOS which will convert a GIF to a monochrome GeoPaint document
by dithering it.  It uses the Stucki method of dithering which is the best,
but slowest type.  High-contrast GIFs often come out looking pretty good
with this utility, but, of ourse, you must be running GEOS to use it.
 
There is also an 80-column GIF viewer for the C128 which will display GIFs
in 16 colors, and I understand that it can generate some pretty nice images.
I can't say that for sure because it requires a 64K VDC which comes standard
with a C128D, but which must be installed as an aftermarket upgrade in a
regular flat-top C128.  I have yet to upgrade mine.


John M. Williams    ___   ___/   /      /    ___/    theenforcer@delphi.com
--




Subject: HELP: geogif
Date: 16 Oct 1995 19:10:16 -0400


	I ftp'd a small program I thought was a Geos supported 
file names geogif.sfx (from nec.funet.fi). It unarc'd into this:

	geogif seq
	geogif/doc seq

 I have a 36 block seq program 
that I THINK is the program geogif.


 jezzydee@clam.rutgers.edu



From: discon@news.dorsai.org (Paul Lieberman)
Subject: Re: HELP: geogif
Date: Thu, 19 Oct 1995 22:11:03 GMT


Chris Gioconda (cyberbyte1@pb.net) wrote:
: GeoGif is VERY slow, it makes GIF's b/w, and it can not read interlaced 
: graphics...the only good sides to using it is that you are able to change 
: the picture, and it's now printable...btw, before downloading the gif you 

	Wait a minute, here.  True, geogif is very slow and makes only a 
b/w pic, but (as far as I know) there's no other c= gif reader or 
converter that makes anywhere NEAR the quality conversions that this 
does.  The other gif readers all make blocky, indistinct pictures.  
Geogif takes a color, photo-quality gif and makes a rather grainy b/w, 
but  still beats all the others.

	BTW #1) After I convert them, I view them with geoview128, which 
actually has better quality than the geos viewers (it's a non-geos 
geopaint vewer).  Almost photo-quality.

	BTW #2) I recently found a non-geos program that converts 
interlaced gif to non-interlaced.  I haven't encountered any interlaced 
gifs since I have the program, so I haven't tried it out yet.  I forget 
the name of the program, but will check if anyone wants. `I think I got 
it on GENIE.

--
**************************************************************************
*   Paul Lieberman             "From out of the depths of Brooklyn..."   *
*   discon@dorsai.org              --       p.lieberman@genie.geis.com   *
**************************************************************************


 12.5.2.x C128 GIF viewer

From: paul.fisher@ferrari.ct.se (Paul Fisher)
Subject: W: 128 80C GIFF VIEWER
Date: Sat, 09 Sep 95 23:29:00 +0200

There is a program called GDS which does the trick, It even saves them to disk
i BASIC 8 format. Then for GEOS  theres GEOGIF which converts to GEOPAINT
format. 
      
The GDS program I have seems to be somewhat incomplete and I sent a postcard a
while back to the author and got no responce (was checking to see if the
Shareware $$ would get to him) 

paul.fisher@ferrari.ct.se
Commodore 64/128 RULE!


From: bpease@erc.cat.syr.edu (Bryan Pease)


>it's problems, pc programs will totally blow away c-128 as far as power,
>performance and resolution.  I still fire up the c-128 from time to time,
>but how long can you live with 16 colors and cga resolution?  Win 95 is an

Try I-Paint which gives 128 users 640x400 resolution and over 200 colors
using interlaced graphics.  And I don't know what you mean by performance;
my 128 can do just as much productivity wise than any pee cee...  ;)


From: csbruce@ccnga.uwaterloo.ca (Craig Bruce)
Subject: Re: W: 128 80c GIFF viewer
Date: Thu, 7 Sep 1995 18:13:59 GMT

jezzydee@clam.rutgers.edu (Jezebel Rebecca Delilah) writes:

>Does anyone know of a C128 Giff Viewer that works in 80 col mode? Or 
>better yet a GIFF to CBM comverter?

There's a program called GDS that will allow you to view GIFs on a C128's
80-column screen if you have 64K of VDC RAM.  However, it doesn't support
dithering, so if you try to look at real pictures, they really look crappy.
Cartoon images look okay.

There's also a program called VBM for use with the ACE operating system.  It
features 640x491 interlaced viewing of black & white bitmap images if you
have 64K of VDC RAM.  However, its images must be in its own special
format.  A C-language conversion program for Unix and MS-DOS systems for
converting XBM and PBM images to the special form is available, but you will
need your own means of converting GIF and JPEG images to XBM or PBM
formats.  Most Unix systems should have some kind of support for this,
supplying either "pbmplus" or "giftoppm", "ppmtopgm", "pgmtopbm", and
"djpeg".  Try "man pnm" for more information.

There are also a number of images in the special VBM format available from
FTP host "ccnga.uwaterloo.ca" in directory "/pub/cbm/graphics/VBM128/images".

Dithered images look very good when viewed with this viewer, IIDSSM.

Keep on Hackin'!

-Craig Bruce
csbruce@ccnga.uwaterloo.ca
"The great thing about being government is that if you are losing the game,
 then you can just change the rules."


--

  12.5.3 VBM

   "pbmtovbm.c" by Craig Bruce.

"pbmtovbm.c" -- previously known as "xbm2vbm.c" -- is available from FTP host
"ccnga.uwaterloo.ca" in directory "/pub/cbm/graphics/VBM128" in directory
"pbmtovbm.c" or from my Homepage under 'My Commodore Programs'.  The URL for
my homepage is:

	"http://ccnga.uwaterloo.ca/~csbruce/"

The program will now accept input in three standard formats: XBM, PBM-ASCII,
and PBM-raw (PBM==Portable BitMap).  The latter two are much more common than
XBM format, since they are the "lowest common denominator" format are are
therefore supported by most graphics packages.  "XBM" is not an IBM graphics
format; it is the X-Windows format for bitmaps; it is, in fact, C code for
the declaration of an array containing the bitmap.

To convert images for VBM, you first need to get yourself some PC/Unix
graphics package that will convert from GIF/JPEG into one of the three
formats that my converter program will accept.

The 'usage' for my C converter program is:

pbmtovbm [filename ...]

If no filename is given, then it reads from stdin and writes to stdout.  If
filenames are given, then input is taken from each input file in turn and
written to the "filename.vbm".  If the suffix of the input filename is ".xbm"
or ".pbm", then the suffix is replaced by the ".vbm" in the output filename.

BTW, the bird was a toucan, not a parrot.  Maybe I can get some more images,
convert them, and make them available.
---



From: Alan Jones <alan.jones@qcs.org>
Subject: ACE and VBM
Date: Wed, 23 Aug 1995 15:45:00 GMT

I have been playing around with ACE14 VBM and VBMPR.
The VBM graphics file format is unique to ACE, yet they can't be
created on a C64/128. :(  The picture is a monochrome (two color)
bitmap that can be as large as 2040 x 64K pixels.  The VBM viewer is a
window into the larger image that can be scrolled around.  A C64 will
display a window of 320 x 200 pixels, while a C128(D) will display 640
x 491 pixels with 64K VDC RAM.  Viewing the image is reasonably
fast if you remember to copy the .vbm file to the ACE ramdisk first.
A collection of .vmb files can be found at ccnga.uwaterloo.ca
/pup/cbm/graphics/VBM128/images.  The largest file is b777.vbm, a view
of the 777 cockpit.

I expected to have difficulty getting VBMPR to print.  I use a Cardco
+G interface with a Star NX-2430 24-pin printer.  I simply locked the
interface in transparent mode, turned on the printer, and entered
vbmpr z:blastoff.vbm.  Amazingly, the Shuttle launch picture was
nicely printed at 80 dpi.  I have not checked the aspect ratio yet.  I
then printed b777.vbm.  The docs were sketchy but I though it would
print the first 640 horizontal pixels, followed by the second..., so
that the image could be assembled by cutting and pasting.  Only the
left portion of the picture was printed.  VBMPR needs to have more
options/parameters.  80 dpi is really an odd size for most printers.
Fortunately my printer has an 8-pin 80 dpi graphics mode, and happily
VBMPR used this mode.  I would like VBMPR to be able to use some of the
other modes particularly 24-pin double (120 dpi), 24-pin triple (180
dpi), 24-pin hex (360 dpi).  No doubt other users would like it to work
with 300 dpi lazer printers or the old Gemini-10X, or even old CBM
printers.

The printouts that I did produce looked quite nice.  They were a bit
slow.  I could try a GeoCable type interface, but I think the 8-pin 80
dpi hardwired mode is the problem.  I would also like to see a spooler
of sorts.  It would be nice if VBMPR could print a file from the ramdisk,
while returning control to ACE for other tasks.  My printer has a 32K buffer
so interruption of the serial buss would not interrupt printing.

It would also be great if we could plot into a VBM format file and
print them as included files with ZED.  I don't want to keep putting
things in Craig Bruce's job jar.  I am anxiously awaiting ACE 15 with
te new and improved ZED.  I do want to say that VBM and VBMPR are very
nice utilities and share my experience with them.

alan.jones@qcs.org


From: Alan Jones <alan.jones@qcs.org>
Subject: VBM
Date: Mon,  4 Sep 1995 17:53:00 GMT



   ---------------------   Text Import Start   ---------------------

From: 057184449-0001@btxgate.de (Arndt Dettke)
Date: Mon, 4 Sep 95 21:07 MSZ
Subject: VBM

a VBM-loader and saver for GoDot (640x400 saver) by Arndt Dettke.


Arndt Dettke
Schillerstr. 10
D-32427 Minden
DxJ-Nr: 057184449-1
Telefon-Nr: 057184449

   ---------------------   Text Import End   ---------------------

I just received this message from Arndt Dettke.  We now have a way to
create modest size VBM images using a C64.  I don't have these
routines, but I do have the Godot demo package and it seems to work
well.  The docs have not been translated into english yet.  Arndt is
still struggling with very limited Internet access.

BTW Bruce, you said "A pair beats no cards."  I think you meant, "An
ACE beats no cards." ;)       alan.jones@qcs.org

___ QWKRR128 V4.32 [R]

From: mparson@io.com (Michael Parson)
Subject: Re: ACE and VBM
Date: 5 Sep 1995 08:58:01 -0500

John Williams  <theenforcer@delphi.com> wrote:
>Craig Bruce <csbruce@ccnga.uwaterloo.ca> writes:
> 
>>>I have been playing around with ACE14 VBM and VBMPR.
>>>The VBM graphics file format is unique to ACE, yet they can't be
>>>created on a C64/128. :(
>>
>>This is true.  Although I don't really know what they should be created
>>_FROM_ on the Commodores.  I figured that it would be much more common to
>>convert them on the bigger systems that you get GIFs and JPEGs from.
> 
>I really do like using ACE, and I would love to try out the VBM utility, but...
>where do I get graphics in VBM format.  I am accustomed to using my '486 to
>convert graphics for use on my C128, usually in GIF format, and I use
>Windows Graphic Workshop which has a large number of formats available for
>conversion.  However, I have never seen an option for VBMs.  Do you know of
>any utilities for PC clones which can extract VBMs from GIFs, JPEGs, BMPs,

I use the PBMplus utilities under UNIX to convert my images from .gif or 
.jpg to .xbm (X11 bitmap).  Then, I use Craig's xbmtovmb (xbm2vbm?) 
utility to convert them to vbm files.  You can get PBMplus for most 
platforms (I've even got it on my Amiga 2000).  You will just need a C 
compiler to compile Craig's final conversion utility.

-- 
Michael Parson


From: csbruce@ccnga.uwaterloo.ca (Craig Bruce)
Subject: Re: VBM
Date: Wed, 6 Sep 1995 15:15:03 GMT


Programming for the VBM format isn't really very difficult.  The basic idea
is to have a header followed by data in the basic format of how the C128's
VDC chip stores bitmaps (the format is officially named after "VDC
BitMap").  Unfortunately, there are three different versions of the format:
version #2, version #3 uncompressed, and version #3 compressed.  The version
#2 format exists because I didn't get the format right the first time.  You
can tell which format the VBM file is in by reading the header.  The header
of all the formats is as follows (you can extract all of this information
from the "pbmtovbm" version 1.99 conversion program):

POS   SIZ   DESC
---   ---   -----
  0     1   the character 'b': $43
  1     1   the character 'm': $4d
  2     1   the binary value $cb
  3     1   the VBM format version number: $02 or $03
  4     2   the width (X) of the image in Hi/Lo format
  6     2   the height (Y) of the image in Hi/Lo format

If the image is in version #2 format, then this is it for the header.
Version #3 images have the following additional header information:

POS   SIZ   DESC
---   ---   -----
  8     1   data-encoding type: $00=uncompressed, $01=RLE-compressed
  9     1   byte code for general RLE repetitions
 10     1   byte code for repeated zeroes
 11     1   byte code for two repeated zeroes
 12     1   byte code for repeated $ff values
 13     1   byte code for two repeated $ff values
 14     2   reserved := 0
 16     2   length of comment text (0 == no comment text)
 18     n   characters of comment text in PETSCII

If the data-encoding type is "uncompressed", then the "repeated" fields are
ignored; otherwise, they contain the binary byte code that is to be used to
trigger an RLE expansion when uncompressing.  For version #3, I allowed the
data to be either compressed or uncompressed because uncompressed data will
be able to be processed and displayed faster, and compressed data will be
shorter.  Or, depending on the storage device and the image involved, the
compressed format may turn out to be faster since fewer characters will be
read from a slow I/O device.

For the uncompressed formats, the raw data is stored row by row from top to
bottom, with each row stored left to right, eight pixels per byte.  The
most-significant bit of the byte will contain the left-most pixel, and the
least-significant bit, the right-most pixel.  Where an image has a width in
pixels that is not evenly divisible by eight, the image is padded with black
pixels to make it so.  Thus, each row of the image occupies an integral
number of uncompressed bytes.  This is also roughly the format that the VDC
chip uses to store bitmaps.

The difference between version #2 and uncompressed version #3 images is that
for version #2 images, "1" bits mean black pixels and "0" bits mean white
pixels, after the X-Windows format.  For version #3 images, the bits have
the opposite meanings.  Yes, this is an unfortunate blunder, but easy to
fix; you just scan through the version #2 bytes of display data and EOR them
with $ff before using them on a display with a black background color and a
white foreground color.

The compressed format uncompresses into exactly the uncompressed format
(sic).  To uncompress compressed data, you read one byte of the data at a
time and compare it against all five of the "repeated" byte values given in
the header.  If the byte doesn't match any of them, then you display the
byte as-is; it's a literal.  Otherwise, if the byte is the code for the
"general repetition", then you read the next byte value which is the literal
value that will be repeated and then read the next byte after that which
gives the number of repetitions to make.  This is sufficient to give you
Run-Length Encoding compression, but I found that I got better performance
if I included additional, shorter RLE sequences for repeated $00 and $ff
strings of both general length and of specific length 2.  You always use the
one that gives you the shortest data.  The sequences are summarized as
follows:

CODE          SEQUENCE
----          ---------
general rep   <code> <literal-byte value> <repetition count>
rep $00       <code> <repetition count>
two $00       <code>
rep $ff       <code> <repetition count>
two $ff       <code>

If you run into a string of only one $00 or $ff byte, then you encode it
simply as a literal.  If you have a literal that you want to encode but it
equals one of the RLE repetition codes, then you must encode it using the
general repetition sequence.  Since this one literal must be encoded using
three bytes, it is possible that you could end up with data that is longer
when compressed than when it is uncompressed, although this is extremely
unlikely.

You can examine the "pbmtovbm" program for algorithms for compressing and
uncompressing the data according to this scheme.  You can statistically
determine what the best code values to use for these five RLE code sequences
for each file you compress, but I have found that the following values work
quite well for the sample data I have tried (mostly dithered images): $31,
$8c, $39, $cc, and $9c, respectively.


-Craig Bruce
csbruce@ccnga.uwaterloo.ca
"The irony, of course, is that if the entire herd of deer were to turn and
 trample the tiger, the tiger wouldn't stand a chance."


---

  12.5.4 IFLI

From: toegelrd@track.informatik.uni-stuttgart.de (Roland Toegel)
Subject: IFLI viewer
Date: 24 Aug 1995 10:58:38 GMT


after serveral talks about IFLI in the past, I noticed, that nearly all
viewer I saw (included in some demopics) don't display the full 200 pixel
height in IFLI.. they bugged in the 4 last lines....

well, they made a small mistake in beginning the screen in line $33..
so, here a viewer which starts in line $30 and displays all 200 lines
correct. (sorry, only in PAL)

it displays IFLI pictures in GUNPAINT format...
that means, flipic1 color  from $4000 to $5fe8
            flipic1 bitmap from $6000 to $7f40
            colorram       from $8000 to $83e8
            flipic2 color  from $8400 to $a3e8
            flipic3 bitmap from $a400 to $c340

and even the $fd30-$fd50 "bug" don't appears after reset or runstop/restore
and restart!

...and!!! it takes only 1 block on the disk (252 bytes)

begin 640 crest_ifli_view
M !!X[AK0[@W<J1"-$M"-(-"-(="-%0.@ (18A%JI<HT4 ZG#S>B#\!N-Z(.%
M6Z @N2_!F3]_B-#WA%GF :)!(&P0Q@&B!*G;A5FI@X5;(&,0HA^]0'^=,/W*
M$/=8[ '<\/M,XORQ6I%8B-#YQEO&6<K0\F"@+,P2T-#[H@G*T/W! ,C,$M#P
M M4 H@G*T/W! ,C,$M#P B0 H@K*T/WJR,P2T-  H@W*T/W! * 9H@;JO>X0
MC1C0O?40C1'0RA#PJ0B-&-"B.(CP!8X1T-#?J7"-$="M$M#0^ZDPC0#=20*-
=V!!*C1;0CA'0[AG03('J>&A82#@H&#\^/3P[.CF-
 
end


--

  12.5.5 SRF

The SRF is a Self Running FLI.  I don't know of any programs that will 
directly convert to SRF, but I have run into a few packages that convert 
from gif to FLI, and know of at least one program that converts from IFF 
to IFLI.  The FLI converter can be found on ftp.funet.fi, the IFF to IFLI 
converter runs on an Amiga, but has not yet been officially released.



XBM is 1 bit bitmap used mostly on UN*X systems.  I use the pbmplus 
utilities (can be found on your favorite UN*X ftp site) to convert my 
graphic files to XBM.  If you have access to an Xwindows terminal and the 
viewer xv, you can load up the image and save it as an XBM directly.  
Using the PBMplus utils, I have to run the following conversions:

gif to ppm    (portable pix map - 24 bit uncompressed color bitmap)
ppm to pgm    (portable grey map - 24 bit uncompressed greyscale image)
pgm to pbm    (portable bit map - 1 bit b/w binary bitmap)
pbm to xbm    (X11 bitmap - 1 bit ASCII (C) rep of a bitmap)
xbm to bm     (Craig Bruce's binary rep of the x11 bitmap for VBM)

I did the first few conversions by hand, then I wrote a nifty script that 
runs them all in sequence, makes life nice if you are converting a whole 
directory of images =)


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

  12.6 SID tunes


Subject: Re: SID to General MIDI - who knows of a utility?
Date: Tue, 30 Jan 96 09:34:15 -0500

Definitive Answer:

1) Michael Schwendt (3schwend@informatik.uni-hamburg.de) has
written a great Sid2MIDI utility to covert Playsid files into
General MIDI.

2) There are rather a lot of nice MIDI conversions at
http://www.city.ac.uk/~xa325/midimenu.htm which have
been heavily developed. Done by me.

3) Registration of this program is $15.

4) This Sid2MIDI even handles pitchbend and separates different
instruments to different tracks.

5) Michael Schwendt wrote Sidplay on the PC.
 

Chris Abbott	(abbottc@delphi.com)



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

  13. TRANSFER

 The CBM General FAQ from comp.sys.cbm discusses this topic widely on the
 view from CBM machines.


  13.1 CD-ROM

 Instead of transferring your favourite games for the emulators, you may be
 tempted finding most of them already cracked on many pirate sites and CD-ROMs,
 though there might be a legal CD out there as well. (Not that pirating would
 be legal, or encouraged by VICE -- it's just the existing situation.)


  13.2 CBM

	 1) An Ibbem floppy drive simply
David> cannot read a Commodore disk, no matter what you do to it and
David> what software you use.
David> 1541 can read and write to IBM disks (using a program which
David> I've heard of but not tried called the Big Blue Reader).

That's partially correct: a 1541 can read and write MS-DOS disks, but
not with the commercial program Big Blue Reader, but with the PD
program 1541-dos written by Richard Hable and Daniel Fandrich.
Available at ftp.funet.fi:/pub/cbm/transfer/1541-dos/.

--

From: e9025800@stud1.tuwien.ac.at (Stefan Froehlich)
Subject: Re: read 1541 floppys with a PC??
Date: 9 May 95 08:58:47 GMT


>>I 'd like to know if there is any way to read 1541 floppies with a 5 1/4 high
>>density floppy disk drive of a PC.
>>I have important documents in easyScript and my 1541 drive is broken, so what i
>>want is to read those disks with my PC and translate the information to a
>>standar file format.

But as the C128 can read foreign disc formats under CP/M which are 
MFM-formatted, it is possible to read PC-floppies with the 1571.

I have done so, there is a special program available, which copies from GCR 
disks directly to MFM disks. The program works with the C128 + 1571 and, too 
with the C64 + 1571, if you modify your hardware a little bit.

Bye, Stefan



From: NEUS%mimi@magic.itg.ti.com


 How do I get files from my PC to C64?
 
There are several ways.  Probably the easiest if you have a 1571 or 1581 drive
is to use software that will allow you to read MS-DOS disks directly.  Two very
good programs I'm aware of are Big Blue Reader and Little Red Reader.  BBR is
much better, but LRR is PD and requires two drives.  Take your pick...
 
If that fails, a program called x1541 will allow you to connect any serial CBM
floppy drive to an IBM through the parallel port.  This also works well, but is
really slow (uses standard slow serial) and you need to build a special cable.
 
Finally, there is a null modem connection.  This also needs some hardware, but
it should be easy to come by.  You will need an RS-232 interface on the
Commodore, and a "null modem cable" which most computer stores should stock as
a standard item.  NOTE--a regular RS-232 cable will not work.  Connect the
cable between RS-232 ports on both computers and simply transfer files between
the two using a batch protocoll (Y-Modem works well) with a standard telecom
package (I use Q-modem on IBM, Desterm on C128).
 
Mike Neus
NEUS@timsg.csc.ti.com


From: louhern@symnet.net (Luis Hernandez)
Subject: Re: How do I get files from my PC to C64?


1. modem or null modem
2. Big Blue Reader (commercial) or Little Red Reader (shareware)-1571 needed.
3. TRANS64_114, available at watson.mbb.sfu.ca /pub/c64/emulators
   This option will also let you save whole-disk images to a 1541 from
   d64 image files (for the emulators).

That's a few of many possibilities.

Use either Big Blue Reader available commercially or even better use 
Little Red Reader which is free or shareware. I can't remember off hand 
where it is available but ARCHIE should be able to tell you. The file 
name is LRR200.sfx. You need at least 2 disk drives (1571 or 1581 to read 
720KB disks).


Subject: Re: 1581 MSDOS ?

> I'm looking for a shareware program or utility that allows me to read MSDOS
> disks on my 1581 in 64 mode.

SOGWAP's Big Blue Reader exists in a 64 and 128 versions, and it will allow
you to read 720K disks on your 1581.
BBR can transfer programs between Amiga, PC, 64, and 128 (native and CP/M).


  Little Red Reader.
It is PD and has no limit on the size of files that it will copy.
It requires a C128 and two disk drives. Can convert MAC text files as well.


From: Sy.Ali@canada.tor250.org (Sy Ali)
Date: 14 Aug 95 03:40:12 
Subject: Re: 1581 MSDOS ?

  I happen to have an 8 block utility which will let you read, and copy
from a 720k IBM (in your 1581) onto a 1541 disk.

| Internet: Sy.Ali@canada.tor250.org


From: paul.fisher@ferrari.ct.se (Paul Fisher)
Subject: FDX000 MSDOS
Date: Wed, 23 Aug 95 21:24:00 +0200

Does anyone know WHY BBR 4.1 can't read normal MSDOS formatted HD disks in
FD drives? What difference is there between the FD MS format and the IBM MS
format? (noticed that with F4 you can read the directory of both sorts) It
returns a HIGH CAPACITY disk error. Doesn't seem to have any thing to do with
size.. 1.44 is 1.44... 

paul.fisher@ferrari.ct.se


 * Kermit

From: chrismc@news-server (Chris McCormack)

: One more thing,  my kermit program takes alost 1 minute per 1K when
: downloading considering my equipment, barring getting a faster modem,
: or etc, what can i do to make it less painful

: current rate:  download  48k in 35 minutes  terrible!

   Kermit is widely mis-understood, and receives a bad rap for speed.
With proper settings, it's actually pretty quick.  The problem is the
default settings impose a nasty overhead by assuming things like a
7-bit link, need to quote a lot of special characters, etc.  The other
drawback is the slow write speed of Commodore disk drives.

   Depending on the terminal program you have, X-modem or Y-modem should
speed things up tremendously.  Most unix versions of Z-modem also support
these protocols - usually under the names sb (for y-modem) and sx (for
x-modem).  Use one of these and downloads should be snappier.

   For a c128, both of these protocols are supported by DesTerm - a very
nice terminal program with snazzy options and robust Vt-100 emulation.


From: Adam.Bergstrom@um.erisoft.se (Adam Bergstrom)
Subject: VIC-20 program transfer PC -> VIC-20
Date: 27 Oct 1995 06:36:01 GMT


OK, I've done a program that lets you transfer programs from the PC
to the VIC-20 through the parallellport. It's really fast, and quite
nice to use if you program alot.
Anybody interested in this  package? If the interest is big enough,
I'll write a manual and make a package with the programs for the
VIC-20 and the PC along with a description for the printer-port
cable.
Of course it'll be freeware.
No use going through the hard work of writing a manual with nobody
to use it later...


E-mail  adam.bergstrom@um.erisoft.se      |



  13.3 Amiga

From: vos@dutiws.twi.tudelft.nl (E.W.C. de Vos)
Subject: Re: Saving to D64FILES possible.
Date: Mon, 1 May 1995 11:38:35 GMT

I don't know if anyone is interested, but I just made a program which can save
to d64files, extract from them, and list the directory contents.
The program is for the Amiga.


Eelko
 -     Eelko de Vos   vos@dutiws.twi.tudelft.nl



  * Amiga Transfer Cable

The diagram for the Amiga to 1541 Cable (The Amiga equivalent to the X1541)
can be fount - at the moment - at URL:
   http://stekt.oulu.fi:/~jopi/electronics/cbm/1541_to_Amiga.gif


	Amiga parallel <-> C64

  * PData	(FTP: ftp.funet.fi, possibly aminet)

 Transfers files between C64-amiga, but quite slowly...


  * (B)-Net by Mr.Sex
	.d64 liikahtaa neban levylle n. minuutissa, zipcodet n. kahdessa.. 


   * Over5 v0.463, by tlr@stacken.kth.se
	FTP: AmiNet in misc/emu/Over5_0.463.lha




for the C64/Amiga
It sets up a 32800 bps serial link between the amiga and the C64... then
you have programs for sending/receiving files/memory/diskblocks as
well as letting you use the amiga as a server for your C64...
--

 * D64transfer

"C64transfer", which can be found at ftp.funet.fi.
It can only handle one file at a time, but it's really reliable (as opposed to Transnib).
However, I recently found an update to C64transfer, called D64transfer, which
can transfer whole D64 files directly to the C64 disk. It uses the original
C64transfer, except for an updated serverprogram on the c64 end, and can
be found at

	pitel_lnx.ibk.fnt.hvu.nl  /pub/c64/D64/D64trans.lha

The transferring is very slow, but it works reliably.

Finnish docs included. Could be in English by now.


  * Jnet

BTW, If you build the cable for the program called Jnet (found on Aminet) you
can use that for Jnet, C64transfer and Transnib. I also have a version of the
Jnet program on the C64 end that's better than the original one (you don't
have to reload Jnet on the Amiga and transfer the server program to the C64
every time).

/Pelle


 * Emul_1541

From: ddp00@wumpus.cc.uow.edu.au (Pearse Daniel David)
Date: 5 Oct 1995 12:30:56 +1000


A program on aminet under /misc/emu called emul_1541.lha
is supposed to make the amiga behave as a c64 drive...

Dan


From: jhsa@isosotka.cs.tut.fi (Salmij{rvi Janne)
Subject: Emul1541, Does it work?
Date: 30 Oct 1995 11:54:13 GMT


Emul1541 is a program and a hardware interface for amiga that makes it
emulate 1541 drive. It connects amiga and c64 and amiga acts as a 1541.
It has been tested on several amigas and several c64s and it doesn't work
with any of them perfectly.

The hardware interface (contains one N7406) has been checked over and over
and it seems to have been built properly. Any help is much appreciated.
Thanks.

				Janne Salmijrvi, jhsa@cs.tut.fi


From: count0@mail.bremen.pop.de (Count Zero)
Subject: Re: Emul1541, Does it work?
Date: 30 Oct 1995 22:31:25 GMT

A friend of mine got it to work by changing something on the schematics,
but when I tried it it still didn't work out for me either, although I got
schematics and U tell me whether it works that way or not ...

Count Zero/Talent


From: s5pjj@csc.liv.ac.uk (P.J. Johnson)
Subject: Re: Emul1541, Does it work?
Date: Tue, 31 Oct 1995 19:28:50 GMT


Emul_1541 is a bit flaky, in that if you reset or crash your c64 while it's
running, you'll invariably crash your migy too. Other than that, I've had no
problems LOADing stuff really. I keep an installed boot disk with Emul_1541 on
which it simply runs from its startup-sequence. This way, when the migy
(inevitably) crashes, you can be back up and running in seconds.(you can keep a
good selection of games on the disk too :-) )
Make sure you've pulled up all the i/o lines in the interface to 5v (open
collectors), and put in a decoupling cap ~0.1Fs between 5v and GND.

BTW: The Emul_1541 lead is similar to the A64/Frodo one, but is NOT the same.
Emul_1541 expects the 'ATN' line to be an INPUT, A64/Frodo need an output.

P.J.J.J.



 * Parload
 * Transnib
 * Copy1581
 * Run64


Run64 was something I got from a pal in Norway. 1451.lha is the name of Dan's
reader (was on Lennon or wherever I was fishing today



 * Hardware Emulation

From: mdaymon@rainbow.rmii.com (Maxwell Daymon)
Subject: Re: possible to format disks c64 on other platforms?

>  The Amiga's disk controller can read and write either MFM or GCR formats.
> It's a bit in a register that switches between these modes.  The Amiga's DOS
> doesn't use GCR, but it doesn't mean you cant use it. :-)
: Note that 1581 disks already are MFM, not GCR.

Use <gasp> the Amiga 1020 drive. The companion to the Amiga 1010, the 
1020 is a double-sided double-density 5.25" disk drive for the Amiga 
computer. It was released with the Amiga 1000 just after 1985 with "Amiga 
Transformer" a software PC-XT emulator.

Alternatively, you can simply plug an adaptor ($5) to a typical PC drive 
into the Amiga 3.5" drive cable (which actually supports both types)

You can read, write, and format 1541, 1571, and 1581 disks with various 
combinations of software such as Disk-2-Disk (1541/1571 with A1020 or 
compatible), or "Read1581" (pretty obvious, eh?) and there are two others 
faintly in my memory, but I'm having a hard time recalling the names.

--
+- Maxwell Daymon -+- mdaymon@rmii.com -+


From: "Edward C. Shaw" <edshaw@iglou.com>
Subject: Re: READING AMIGA DISKS ON AN IBM
Date: Fri, 22 Sep 1995 18:51:25 GMT

There existed once a couple of files for early Amiga users to emulate
the 8088 computer.  I think they were Cross-DOS and DOS2DOS.  This must
be what you refer to when you say you are aware of going one direction,
but not the other.  Otherwise, I am unaware of any AMIGA emulation
scheme for PC.



From: K.E.W.Thacker@cs.cf.ac.uk (K E W Thacker)
Subject: Re: Emulator required
Date: Tue, 14 Nov 1995 10:06:39 GMT


Keith Butler <keith@butlerk.demon.co.uk> writes:
|> Can someone tell me where I can get hold of an emulator/piece of 
|> software that will enable me to read my Amiga disks on my PC, as I have 
|> a load of samples/mods etc I want copied across?
Do things the other way around, get some software for the Amiga to read
PC disks. The PC is not capable of reading Amiga disks because the Amiga
uses a completely different disk structure and method of storing data.

Look for MessyDOS or if you have Workbench 2.1 or above, there is CrossDOS.
In workbench2.1 or above, put in the extras disk and copy the PC0 icon from
the DosDrivers draw to the DosDrivers draw of your Workbench disk. Reboot
and now you can read PC DD disks.

If you want to read HD disks from PC, then buy a HD drive compatible with
Amiga (you will need WOrkbench2.0 or above to use this)., otherwise
you are stuck using DD disks .

Hope that helps!

Kev
--
K.E.W.Thacker@cs.cf.ac.uk

Unofficial Amstrad WWW Resource:
http://www.cs.cf.ac.uk/User/K.E.W.Thacker/Amstrad/index.html

Author of A-CPC (Amstrad emulator for Amiga):
ftp: Aminet: /pub/misc/emu/acpc_dem.lha
--



From: lwilton@BIX.com (Loren Wilton)
Subject: Re: Amiga floppys on PC
Date: 30 Oct 1995 01:46:25 GMT


pdolding@metz.une.edu.au (Crystania) wrote:
>Christian Kersting (kerstic@urix0.uni-muenster.de) wrote:
>: Per Bengtsson (per.bengtsson.swe2062@oasis.icl.co.uk) wrote:
>: : Is it possible to read Amiga Double Density floppys on a PC drive and copy 
>: : the files from it to PC format? NOT RUNNING IT! (to avoid getting flamed)
>: : In case it's possible, what software do I need?
>: 
>: 
>: I have never heard of PC reading Amiga formatted disks. but an Amiga with
>: Crossdos (any amiga since workbench2.0) can read/write/format pc disks.
>
>The Ibm Pc and Clones can do it with the correct program. It is just a
>mod of what lets these pc format disk at many different formats. One
>I am looking forward to try out if it is possable to format them  on
>the Ibm. If some one could get the information on c64-c128 disks
>and set up a program to read, write and format these on a ibm
>if the drives in the curent ones can be set to do it.

I'm sorry, but this is flat wrong, at least if you are planning on using
the standard PC floppy controller chip.  Now, if you build your own hardware
floppy drive interface, it should be quite easy to handle either Amiga, 1541,
or Apple [] format disks.  However, the standard PC floppy controller chip
is *completely* incapable of reading any of these formats.

The PC floppy controller chip is very intellegent at what it does.  However,
it has a "narrow" interface to the PC.  This means that you can only tell it 
to do certain things.  You can only select a very few data clock rates,
such as 250KHz, 500KHz, 1MHz, and sometimes 2MHz.  This means that you can't
read or write most of either Apple {} disks or C64 disks, because they are
recorded at clock rates the PC chip can't deal with (without hardware mods).

Also, the PC floppy controller deals in MFM encoding.  But there are several
ways to do MFM, all equally valid.  The PC controller only recognizes one
of these ways.  That's fine, but the Amiga disks, while being MFM, use
different sync byte patterns from the PC chips.  So the PC chip can't find
the start of address and start of data sectors no matter how much it wants to!
Also, the chip can't read GCR encoding at all, so it can't read C-64 or
Apple {} disks, both of which are GCR encoded.

The Amiga has a very stupid floppy controller.  The side effect of this is
that the processor has a "wider" interface to the thing.  So it can be made
to read and write some forms of IBM PC disks, as well as native Amiga disks.
But even it can't deal reliably with a C-64 or Apple[] disk, since it can't
generate the necessary oddbal data clock rates.

The PC floppy controller allows you to change the bit rate to one of several
preselected rates.  It allows you to select the sector size and sectors per
track.  It allows you to have a little control over the gap lengths between
the address and data and between the sectors.  However, it doesn't allow you
to change the sync byte patterns, it doesn't allow you any coding but MFM,
and it doesn't let you use odd clock rates.

	Loren




  13.4 PC

  13.4.1 What you'll need

: What do I use to convert games to and from .D64 format? I've got SF2 for
: PC but I'd like to play it on my regular C-64. Thanks.

You need your commie disk drive, a special cable, and trans64 (or one of the
other transfer programs).
Trans64 will tell you how to build the cable, or
if you buy one of the emulators (or at least C64S) it comes with one. 

 ---
all you need for converting *.D64 back to c64 disk image
file is:

- a working 1541 etc. disk drive
- a cable that connects your PC's(?) printer port to 1541 etc. drive.
- a program that transfers the files back and forth PC and 1541

First you can download a file called X1541.ZIP, which you can find
from most of the c64 ftp-sites. It is a simple program that handles
the *.d64 files. 
X1541 includes the instructions for building a cable used to transfer
*.D64 files.


: Well, the problem with transferring D64 files on a real C64 is that you
: need a drive that is bigger than a 1541, either a 1571 or 81 because the
: D64 files are about 680 block big.

With Trans64, Star Commander etc you can transfer a .d64 directly to the 
disk, not as a file, but the disk becomes an exact replica of the .d64.  



 Using CBM printer

>The desired interface would then be a piece of
>hardware/software that takes the PC printer port output, processes it,
>then turns in into what the CBM printer expects to see.
 
A Plus-4 and an RS-232 interface and print it to the PC's com port instead
of the LPT port.  I know of no interface that will do what you want.  The only
PC to COMMODORE printer programs I know of all run as software (Device
drivers generally) in the PC.



From: Phil Hoff <phoff@ecst.csuchico.edu>
Subject: Re: PC <-> CBM Printer ?
Date: 8 Jan 1996 17:16:40 GMT

Glenn Webster <glenn@hexa.demon.co.uk> wrote:
>
> I know you can have a cable (Geocable) from your IBM PC printer to your 
> C=64, but is there one for a CBM Printer to the IBM PC parallel port? If 
> not, does anyone have a diagram so I can get one made?
> 
> Thanks in advance.
> 
> Glenn

The software you need is called CBMPR11.ZIP.  It is available at
ftp.funet.fi/pub/cbm/c64/emulation/transfer


From: Phil Hoff <phoff@ecst.csuchico.edu>
Subject: Re: MPS 801 to IBM serial port
Date: 12 Feb 1996 16:51:39 GMT

> On 12 Feb 1996, Kenneth A. Turner wrote:

> > I read in Gookin's DOS FOR DUMMIES that the serial port for the 
> > IBM PC can be used for some non-IBM printers.  So going on that, 
> > and if an adapter can be found, can the IBM run a Commodore printer > 

At
funet.fi/pub/cbm/c64/emulation/transfer
there are two files called CBMPR11.ZIP and CBMPR11.README. The readme
file is a single page and has a diagram for the cable to connect the
C= printer to the PC. The zip file, when unzipped, generates a file
that runs on the PC called CBMPR.COM and takes care of generating
the correct output to the cable.


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


From: aa122@detroit.freenet.org (John F Davis)
Subject: Re: Hooking a Commodore printer to PC ?
Date: 2 Nov 1995 17:57:16 GMT


In a previous article, jpollard@scws28.harvard.edu (Jack Pollard) says:

>Hi, I've got a not so old STAR nx1000c printer banging around my house
>and no printer for my PC. Is there a way to interface them ? Does Dtar
>provide pc compatible serial modules to simply plug into the printer ?
>thanks in advance.
 
The answer to all your questions is YES.
 
There is a program and cable that will allow you to use a Commodore printer
on a MS-DOS computer.
 
And on the STAR printers which had "Plug IN Modules" (I don't remember if the
nx1000c was on that list) you could get three or 4 that I knew of.  CBM,
RS-232, Centronics and I think either Apple, Atari or both. Cart's generally
contain character ROM and interface electronics.
 
Lastly  I don't know if you can still get them however
 
-- 
   John F Davis In Delightful Detroit, Mi.    aa122@detroit.freenet.org
         "Nothing adds excitement to your life like something
         that is clearly none of your business!"     Battista

From: jkeyerleber@bailey.com (John P. Keyerleber)
Subject: Re: Hooking a Commodore printer to PC ?
Date: Thu, 02 Nov 1995 19:45:04 GMT

See http://www.coast.net/simtel/msdos/info/c64topc.zip



From: hstevens@freenet.columbus.oh.us (Harold Stevens)
Subject: Re: Hooking a Commodore printer to PC ?
Date: 3 Nov 1995 08:26:39 -0500

John F Davis (aa122@detroit.freenet.org) wrote:

: The answer to all your questions is YES.
:  
: There is a program and cable that will allow you to use a Commodore printer
: on a MS-DOS computer.
:  
: And on the STAR printers which had "Plug IN Modules" (I don't remember if the
: nx1000c was on that list) you could get three or 4 that I knew of.  CBM,
: RS-232, Centronics and I think either Apple, Atari or both. Cart's generally
: contain charecter rom and interface electronics.

Sorry, but the NX-1000C uses the serial cable coming from the disk drive
in a daisy chain configuration. You have to get a special adaptor to
plug the PC's serial or Centronics cable into the CBM serial port.

:
Lastly  I don't know if you can still get them however :  

Aprotek still makes the CBM to IBM adaptor and you might be able to get it
from Creative Micro Design.
-- 
--Harold Stevens

Internet addresses: hstevens@freenet.columbus.oh.us
                    h.stevens5@genie.com



  13.4.2 PC Transfer Cable

 The required cable is not difficult to make, even if you are unexperienced in
 soldering. The pins are usually numbered on the connectors, so look carefully.

 However, if it won't work, here are a few things to check out:

  * Make sure all connections shown in the instructions are included.
  * Test it with a multimeter to see there is no short circuit.
  * Check (with C64) your drive is OK.
  * Check the delay settings you're using on the program.

  * If your PC is too fast, (e.g. a 486/66) it may not even recognize the disk
    drive. All you'll need to do is to take the computer out of turbo.

  * On some machines there is a setup/CMOS procedure for making your parallel
    port send and receive insted of send only. Check your setup and see if it's
    locked into send only.

 I'm sorry to tell you that your parallel port seems to be one
of those who wouldn't run with the transfer programs. The only possibility
to get any of these programs work on your PC would be to by a second
parallel port and to try it with this port. I don't know if this will work
but it's the only thought I actually have :-(
--


From: NEUS@timsg.csc.ti.com (Mike Neus)
Subject: Re: Help!- .d64 to 1541 transfer
Date: 6 Nov 1995 17:02:44 GMT

In article <47h705$msh@news.nevada.edu>, mcalavy@nevada.edu says...

>   You need a "bidirectional" parallel port.  Even if you have one, it 
>needs to be enabled.  (almost always via jumper setting).  Most PC 
>hardware is cheap, even if it costs alot of money.  Since most people 
>only need t send data out to their printer, that's all it can do.  A 
>bidirectional port can also read from the port, which is needed to, well, 
>read from the port....

This is not true.  I do not have bidirectional ports and the program works
fine.  True bidirectional ports are rare.  Always double check the wiring
first.  Try slowing the PC down by taking it out of turbo mode.  Do you know
if the 1541 even works?

|Mike Neus 


>Could there be some minor difference between the old 1541 and the
>newer 1541 II that causes this problem?

the 1541, a 1541-II, and a 1581, and all of the external disk drives 
work just fine.
 X1541, Trans64/Star commander work fine with my 1541-II




From: i942299@redgum.bendigo.latrobe.edu.au (Loon)

one thing that had me stumped for a little while with x1541 was that the
parallel port at $378 is actually lpt2.
lpt1 refers to a port at $3bc which is the address used by those combo
mono display/printer cards.



From: corey@cs.utexas.edu (Corey Cooper)
Subject: x1541 cable stuff ...
Date: 6 Sep 1995 17:07:13 -0500

Finally got my x1541 cable.  Now that it's here, it seems that almost 
everything I ever had for my 64 is now available on one of the ftp 
sites...  almost.

Well, I have a few questions.  First, I didn't read anywhere about WHEN 
to connect my 1571 to my PC.  Figured it didn't make much difference and 
went by the old rule of turning the PC off, connecting peripherals, and 
turning it back on.  This FRIED my CMOS battery.  I want everyone to see 
this: THIS FRIED MY CMOS BATTERY.  Had to set my CMOS settings several 
times to get things back to normal and now I'm afraid to turn the thing off.
Be careful.

After restarting everthing, I turned the drive on and then connected to my
PC and everything seems to work fine.  Trans64 transfers great but can't
seem to get Star Commander to recognize my drive.  BTW, whomever the
author of that program is: it looks GREAT, very convenient.  But it must
have taken me 30 minutes to figure out how to change the panels to access
my 1571.  That is VERY WELL HIDDEN in the docs.  Even then it said my 1571
wasn't connected ... 

A while back I remember people discussing the problems of faster CPUs and
corruption when using Trans64 to copy disks.  I remember several people
stating that taking the computer out of turbo mode seemed to solve the
problem.  Can someone tell me what the final word on this is? 

For me, copying a disk when the PC is in turbo mode had the effect of 
Trans64 seeming to miss a few of the last sectors in the final tracks of 
each section (that is, that last few sectors of the last track with 21 
sectors, the last few sectors of the last track with 20 sectors, in 
ascending order).

I found that if I took the computer out of turbo mode, began copying a 
disk, let it proceed for about 6 to 8 tracks, and then put the PC back in 
turbo mode, everything worked fine.  I only have to do that for the first 
disk, after that they all do fine in turbo mode.

Anyone else have insight into this?

-Corey


From: ckaiser@sdcc13.ucsd.edu (Po-Ching Lives!)
Subject: Re: D64 images, and some questions
Date: 5 Sep 1995 15:08:59 GMT


>Ok, I have the program to convert a D64 to regular commie language, but 
>it needs a 1541 and a 1571...Is there any way I can download a D64 to a 
>1541, without the '71? I know a 1541 disk is too small for a 170K image, 
>but there has to be some way to do it...And another thing, while Im on 
>the subject, is there ANY version of PKUnzip 2.4 for the commie? I will 
>pay money right now for that miracle...

You can, in answer to your first question, do the following:
download the image to a PC, use Trans64 or X1541 and a LPT-serial
cable, and use the PC to write the d64 to the disk. And you *could*
use a 1581 if you like. ;-)

In answer to your second question, there IS a pkzip compatible 64
unzipper, but really due to memory constraints it cannot be called
reliable. If you want it, though, I think it's on my CWI site
(ftp://ftp.armory.com/pub/user/spectre) or on Craig Bruce's
(ftp://ccnga.uwaterloo.ca/). IMO, though, you're better off with
Phil Katz's REAL version -- it's just plain faster too.

Toodles, Cameron Kaiser
ckaiser@ucsd.edu
visit the CWI home page: http://www.armory.com/~spectre/cwi.html

***

From: bktiller@aol.com (Bktiller) >>> Byron Tiller <<<
Subject: Re: Trans64 recognizes 1541, but C64S does not?

I had this problem as well.  It ended up to be a setting on the parallel
card in the PC.  Basically you need to set your port to bi-directional,
and PERHAPS not to any other setting like ECP/EPP .  I added a cheap-o
second LPT port card and just cabled up to that, since the dox for my
expensive super-I/O card were mis-leading and/or wrong.  Hope this
helps...



  13.4.3 PC Transfer Programs

  * x1541.exe

	Old, actually the x1541.exe was the first C64 file copier for the PC.
	Shareware. Not very fast; nowadays considered outdated and buggy. Has
	companion prg CBMPR.EXE to drive CBM serial printers.

 The program shows the interface cable pin configuration upon running. A  PC
 Centronics port is going to emulate CBM serial bus.

 Using 1571, 1581 (or even 1541) to read PC disks is possible, but first you
 have to get a utility program enabling it to your C64. The x1541 does not
 need anything in the Commodore end.


From: Leopoldo Ghielmetti <Leopoldo.Ghielmetti@epfl.ch>

after a couple of years and many requests I have found the time for complete a
new version of the famous :-) X1541.

Really it isn't a X1541 but a I1541 plus a U1541.

The I1541 is a "driver" that install it on the DOS int 14H and handle all the
requests
for the CBM interface.

The U1541 is a program for sending and receiving files from the CBM interface
(it use
the I1541 driver).
 
This time the user interface isn't a good one as for the X1541 (if the X1541
interface was a good one :-) ) but this time you have the possibility to write yourself
all the applications you want, simple using the I1541 driver. The set of services
is documented in the Ralph Brown interrupt list format.

FTP: ccnga.uwaterloo.ca


  * Trans64

From: schwall@zeus.informatik.uni-bonn.de (Bernhard Schwall)
Subject: Trans64 1.22
Date: 6 Oct 1995 00:05:16 GMT


Hallo,

I've uploaded the new version of Trans64 (1.22) to:

ftp.rz.uni-hildesheim.de
frodo.hiof.no
ccnga.uwaterloo.ca
ftp.giga.or.at
nic.funet.fi
ftp.seattlelab.com

Trans64 is a program to transfer files between the PC and a  C64 floppydrive.
The floppy is  connected with a simple  cable to the  parallelport of the PC.
You  can  transfer  files among  virtual disks,  virtual tapes,  dos and  the
floppydrive.  Also you  can  transfer  whole disks if a 1541, 1570 or 1571 is
connected.  The cable  used for the connection is  either the cable  used  by 
X1541  or the  cable used  by  Disk64E.  The description of  the cable can be
found in the online-help of Trans64.

Bernhard Schwall



From: TJOE1@delphi.com
Subject: What do I use to convert games to .D64 format?
Date: 19 Jun 1995 02:32:39 GMT


   > What do I use to convert games to and from .D64 format? I've got SF2
   >for PC but I'd like to play it on a regular C-64.


Then get Trans-64, which supports fast disk access.
For instance, you can convert a whole .D64 image
over to a real 1541 disk in about 3 minutes using it.
FTP to lennon.engr.wisc.edu then /pub/c64/utils and look for
files with names like tr64-118.zip and x1541.doc
x1541.doc has instructions on how to build the x1541 cable.

Even if you don't intend to make the cable, Trans-64 is great
for organizing and manipulating .D64 and .T64 images.

Also, if you have access to two 1571 drives, and you have a 5-1/4 drive
on your PC, you can do it without the X1541 cable. Its a rather
elaborate process but if you want to go this route, email me.

Since you may need all the track and sector info in the .D64 file,
I don't recommend trying to transfer each file in the image via modem.

If you need help with any of this, let me know.

    TJoe


> Is it at all possible to convert the emulator disk image files ".d64" onto a 
>disk for use in a real commodore?


- Trans64 (TR64_118.ZIP), it takes about 7-9 minutes to transfer a whole
disk image with this program (X1541 takes about 9 minutes), but this
program can handle also *.T64 tape images. (I don't know if this
program doesn't like my PC, but there occurred lockups frequently and
I had to cold-boot my computer.)

> Trans64 (tr64_114.zip). It can copy between disks and tapes, too.

****
 kasittaakseni .P00 tiedostot siirtyvat myos.



From: techie@ccsnet.com
Date: Fri, 17 Nov 95 21:03:15 EST

try Trans64 v1.22, it's a great program, it offers slow, fast, and
turbo, and operates perfectly in all modes!



  * Disk64e

Subject: Re: Which cable is better? x1541 or Trans64?

You mean the X1541 and the Disk64E cable, don't you? Disk64E, the predecessor
of Trans64 (written by the father of the author of Trans64) used ONLY the
Disk64E cable, but Trans64 uses both of them. The X1541 seems to have become a
standard as the other transfer utilities (e.g. The Star Commander, written by
me ;-) ) and the emulators use it, as well (I'm sure about C64S, does PC64 also
use the X1541 cable?). Although the cables are different only in their pin outs
(and not their usage) I think the X1541 cable would be a better choice.
Good luck!

Joe Forster/STA
sta@ludens.elte.hu



 * Star Commander	written in Borland Pascal 7.0.

- Star Commander (SC_BETA5A.ZIP). This is fastest I've seen. In fastest 
mode it can transfer a whole disk image at 2 and half minutes (!).
This one I prefer the most. I'm not sure if it can handle *.T64 files,
but in speed it's superior with *.D64 files. (This worked perfectly
without any lockups in my machine)

Olmi
-- 


From: u9411127@muss.cis.McMaster.CA (T.A.Rahim)
Date: 7 Jun 1995 17:02:49 -0400


   Well I do have a program for the PC (XFERPC(??) that simply has a little 
file from $0334-$0400 (c64) that receives a file from the PC by typing 
"x64.exe filename". The only problem is I don't have a PC. I know there 
is one like that for the amiga but I forgot who had it!





 * Emulators

  ** PC64

 >> So, can you port files back to the C64 with the PC64 (which I'd
 >> prefer to use) easily?

the built-in transfer in PC64 works in both directions. PC to C64 is 2:30
min and C64 to PC is 1:40 min per disk image. And it's safe.
But it works only in the registered version.



  ** Com1541 (C64S)

 Com1541 is only available with the registered version of C64S, so there's
 no doubt this is the most expensive transfer program. Supports transfer from
 1541 to the PC only.



From: dave@maths.newcastle.edu.au (David M. Williams)
Subject: com1541 and P90
Date: 10 Dec 1995 22:55:38 GMT

  I have a Pentium 90 with one LPT port (at 378H) and I just can't get the
com1541 program from C64S (both 1.1c and 2.0a) to work properly.  It appears
to initialise the 1541 correctly, but then any options like getting a
directory or copying a disk just cause a load of "Device not present" (or
something similiar) errors.
  When I tried the cable and com1541 on a 486DX2/66 all worked fine.  On a
386SX/16 laptop the directory could be read, but the disk couldn't be copied
- it just came up with ?? symbols everywhere.


 David Williams


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



From: scroll@nordnett.no (Ruben Spaans)
Subject: Re: PC->1541
Date: 15 Oct 1995 15:36:48 GMT

: : Can anyone tell me of a utility to convert a .d64 disk
: : image into an actual C64 disk [using the x1541 cable].. In
: : other words, the reverse of com1541 that comes with C64S..
: : I don't want to write files but actual disk images.. Thanks

: Well, would that be available for Amiga -=> C64, too?


For those who don't want to use a cable (?) or for those who don't have a 
cable, I've made a little program which does the job... It runs in C128 
mode, requires a 1764/1750, a 1571/1581/fd-2/4000 and a 1541. It 
transfers one diskside in 2 minutes and some seconds. I know the 
requirements are steep but I was sloppy when I coded it. I made this 
proggy because I couldn't get my X1541 cable to work.

If someone wants it, just drop me a mail, and I'll send it (in .d64 
(.d128? he-he) format). 

Ruben Spaans (Scroll/Megastyle)



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


From: ez13942@nyssa.swt.edu (Bo)
Subject: Re: HELP! How do I transfer .d64 and .t64 files to a CBM disk?
Date: 21 Oct 95 17:02:41 CDT


   Question then.. do you have some manner to get programs which you 
receive from ftp sights onto a commodore disk which has a higher capacity
than a 1541 disk?  

  That is, do you have 1. a) Modem & ability to download from your account or
                     or   b) Big Blue Reader, to xfer from a pc to c64/128
                     or   c) modem connection with a pc for xfers
                 and   2.    1581, 1571, or CMD device which can hold more
                             than 170k files.
                 and   3. some minor programming ability
		 and   4. Access to a PC, or pkunzip at least.

    If so, then you can retrieve the files as follows:

      Log on to the above site, and change to the games directory,
  then go into the /a directory and find the alter ego zipped program.
  (probably 'alterego.zip').  Then 'get' the file in 'bin' format and transfer 
  it to to some sort of pc compatible with pkunzip on it.  Unzip the file: at 
  this point, a series of "*.d64" files should issue forth, one for each alter
  ego disk.  

      Nows the hard part.  You have to transfer the .d64 files onto some
  sort of commodore disk.  Each .d64 file is about 174k (689 blocks), which is 
  why they won't fit on a single 1541 disk. Copy the d64 files onto a series
  of 1581 or 1571 disks so you can transfer them to 1541 format.  I have
  all my files on a pc hard drive, and transfer them to 1581 disks with 
  Big Blue Reader.  But you do this however you can.

Now, type the following program into your c64 computer and save it:


10 input"drives",d1,d2:ifd1=d2ord1<7ord2<7then10
20 input"enter filename of d64 file";f$
30 open4,d1,15:open3,d1,3,f$+",s,r":input#4,e
40 if e>0then close3:open3,d1,3,f$+",p,r":input#4,e:if e then close3:close4:end
50 open1,d2,15,"i0":open2,d2,2,"#":t=1:s=0:gosub100
60 for t=1to17: for s=0to20:gosub100:next:next
70 for t=18to24:for s=0to18:gosub100:next:next
80 for t=25to30:for s=0to17:gosub100:next:next
90 for t=31to25:for s=0to16:gosub100:next:next: close3:close4:close2:close1:end
100 b1$="":b2$=""
110 for i=0 to  9: get#3,a$: b1$=b1$+chr$(asc(a$+chr$(0))):next
120 for i=10 to 255:get#3,a$:b2$=b2$+chr$(asc(a$+chr$(0))):next
130 print#1,"b-p";2;0:print#1,"u2:";2;0;t;s
140 for i=0to9:print#2,mid$(b1$,i+1,1);:next
150 for i=10to255:print#2,mid$(b2$,i-9,1);:next
160 print"b-p";2;0:return


  When you run the program, the first drive given will be the drive on which
the *.d64 file is found (not a 1541), while the second drive will be a
1541 with a blank, PRE-FORMATTED disk.  Run this program for each *.d64
file, for each disk.

   The above program was adapted from memory of the c128 program I wrote,
and it SHOULD work.  If it doesn't, let me know and I'll debug it. 



******************************************************************************

  13.5 CBM Networking




 * prlink

> I'm proud to announce prlink 0.9.2, my transfer system for Commodore
> 8-bit computers connected to an Amiga or a PC (running Linux or
> MS-DOS).  This is an absolute must for coders looking for a decent
> cross-assembler platform, and for other people who appreciate a
> freeware transfer system.

...

> You can download prlink from ftp.funet.fi:
>
>    Source distribution:
>	/pub/cbm/transfer/CBM-to-PC/prlink-0.9.2.tar.gz
>
>    DOS binary distribution: ...
>	/pub/cbm/transfer/CBM-to-PC/prlnk092.zip
>
>    Amiga binary distribution:
>	/pub/cbm/transfer/Amiga/prlink-amiga-0.9.2.lha
>	(not yet available)

I uploaded the Amiga source + binary kit to ftp.funet.fi:pub/cbm/incoming.
It is hopefully available soon.

-Olaf.
--
___ Olaf 'Rhialto' Seibert      rhialto@mbfys.kun.nl      The only excuse
\X/    for making a useless thing is that one admires it intensely. -O.W.




 * SERVER64

LOAD"$",8
Or make a small basic program save it and then reload it.
Press ESC to exit SERVER64.


Windows
-------
It won't work, this program uses the CPU for microsecond timing, so even
under DOS if you push too many buttons you can screw up the timing so
don't say I didn't warn you!

Then this important notice
--------------------------
The author shall not be held liable for any direct or indirect damage
resulting
from or seeming to result from use of this program.


I'd like to thank the following people for helping me out with this program.
*Philip Zembrod (documentation)
*Jaap Verhoeven (protocol documentation)
*Bernard Schwall (source of his send/receive routines)


To do
-----
*Support for printer.
*command support and easy directory manipulation.
*Support for .T64, .D64 and others.
*Fastloader support (can somebody send me info on this).



From: PostMan@jedi-server (Post Office Clerk)
Subject: Re: Using PC as 1541 ?
Date: Mon, 22 Jan 96 20:20:04 GMT

In a contribution about Using PC as 1541 ?, robin@jytol.fi wrote:
>Is there any 1541 emulator for PC's ? I need to connect my C128D to my old
>Commodore PC 10-III and I like to use PC-harddisk just like 1541. There is
>that kind of 1541 emulator for Amiga but is this possible on PC ;) ?

Yep,

I wrote it a year ago and updated it just a few days ago.
you can find it at ccnga.uwaterloo.ca

new version 0.50
/pub/incoming/server64.txt
/pub/incoming/server64.zip

old version 0.01 probally in
/pub/cbm/emulators/server64.zip



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

From: nelemans@ct.utwente.nl (Yvo Nelemans)
Subject: PC as fileserver
Date: Sun, 21 Jan 96 20:40:54 GMT

uploaded to: ccnga.uwaterloo.ca
directory: /pub/incoming
files: server64.zip
       server64.txt

File Server for the C64 v0.50, Copyright (c) 1994-1996 by Yvo Nelemans


Why did I write this program ?
------------------------------
In 1994 I got a C64 from a friend who wanted it to throw away. The problem
I faced then was that I didn't have a diskdrive of datacassete anymore.
Games I had enough on mine PC which I used for the emulators there.
I started to work on this program, work on it went really slow because of
lack of documentation. But thanks to Philip Zembrod I got a copie of the
pages
from the commodore reference manual. At that time I could work on it for
some weeks, but now I've got some time left and got it to work at last.
I've made it cardware, because I like getting lot's of post so if you use
this program just send me a postcard.


What can this program do
------------------------
*LOAD a file from the current directory to your C64.
*LOAD a directory (LOAD"$",8)
*SAVE a file from the C64 to the current directory.

You CAN'T send commands.
Also this program seems to work correctly on mine 386DX-40 and Pentium 100,
it should work on different configurations also but I haven't been able to
check this. Warning this program uses a waiting routine which calibrates
it self to 10 microseconds resolution, if your PC is to slow this may mean
that it doesn't work. (I think only a fast 286 can handle it but don't now
for sure).

This program supports two types of cables. A cable as you used for X1541
or a cable as you used for DISK64E/TRANS64. I've listed the information
to build such a cable below.

I've rewritten a few parts it should be a bit more stable then the previous
version I released.


Example of how to use this program.
-----------------------------------
Start your PC
Start your C64
Start SERVER64 on the PC
make sure you have a valid BINARY file in the current directory of your PC
type LOAD"qix.bin",8 on the C64
and run it.
Or to get a directory you type


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

  *  64NET

From: rja@dce.vic.gov.au (Russell Alphey)
Subject: Re: Files from Pc - C64
Date: 7 Jun 1995 09:39:26 +1000


> 64NET transfers files from PC 
> (or AMIGA) to c64 through the parallel or serial port ?


****
From: piiraine@mopo.cc.lut.fi (Antti Piirainen)
Subject: Re: c64 - PC kytkenta


PC-levyj{ (kova & korput) saadaan k{ytetty{ 64Net-nimisen ohjelmiston
kanssa, kaapeli k{ytt{{ mm. 64:n user porttia. Rekister|inti on
ohjelman k{ytt{miseksi l{hinn{ pakkotoimenpide, hinta noin 50-60 USD


64NET v1.80 features...these supersede features mentioned further on.

This shareware version allows all features of the registered version except
saving from the 64 to the PC.

New features: Track and sector support on 64NET drives, transparent handling
of various archive types, including .D64, CBM zipcode (1!...), .zip, .arj,
etc..  GEOS is supported, but requires an add-on driver not supplied in this
bundle.  Negotiations are underway with the German author of the GEOS patch to
determine how it can be distributed.

*** 128 mode support is now a reality!!! ***

64NET v1.65 features:

Some quick points about 64NET:

*    64NET is a network redirector system which allows a C64 (or C128/C65 in
C64 emulation modes) to access the logical drives of a PC.
*    64NET is _NOT_ a BBS networking programme! (However work on a "dial-up"
extension to the system is under consideration).
*    64NET requires ABSOLUTELY NO DISK PARTITIONING or other nasty things
like that to mount the C64 filesystem.  All files are stored as normal PC-DOS
files, and there are NO INDEX FILES, ie you can copy, delete, rename the
files stored as you like. However it is recommended that you maintain the .N64
extension.
*    Upto 256 partitions can be allocated, with partition numbers ranging from
1 to 32767, including direct links to subdirectories.  Partitions can also
be names, eg. "DH0".
*    LOAD, SAVE, OPEN, CLOSE, GET#/GETIN/CHRIN, PRINT#/CHROUT are all
supported at the assembly code level.

So what does this DEMO version do and not do?

*    SAVE will have no real effect, although it will appear to.
*    OPEN will only work to read from files, with the exception of the
command channel which can be written to.
*    All networking facilities (user id's, logons etc) are intact.
*    BURST LOADING is 100% in (with a C128 loading 200 blocks takes approx 3
seconds! - ie upto 20KB/second)
*    All the other frilly bits and pieces are in.


OK, so what do i need apart from this archive??


  The 64NET interface cable

 This cable connects from the user port of the C64/C128/C65 to a printer port
 on your IBM compatible.  The required pinouts are below:

     USER Port      PC Printer Port
     ------------------------------
     A (GND)        25 (GND)
     C (pb0)        10 (an input line)
     D (pb1)        11 (an input line)
     E (pb2)        12 (an input line)
     F (pb3)        5 (db3)
     H (pb4)        6 (db4)
     J (pb5)        7 (db5)
     K (pb6)        8 (db6)
     L (pb7)        9 (db7)

There are no components involved, just connect the appropriate pins and your
set!


     Transfer any C64 files to the IBM by any means and LOAD them using 64NET.
     They can also be converted to native .N64 format using the CVTN64 
     programme to allow 16 character file names.

     LOAD any of the programmes from the EXAMPLES directory. 
     NOTE: To move into a subdirectory you can simply LOAD the directory name,
           or for those already familiar with subdirectories on C64 devices
           you may use the CD or CP disk commands.

     NOTE: Any action which actually requires writing to the PC's drives will 
     not function in the DEMO version.  This may include using OPEN to read a 
     directory under certain circumstance.


If you really like the 64NET system, and would like to purchase the commercial
version, please contact the closest 64NET dealer to you:


     Australia:	Russell Alphey
		R.Alphey@agriculture.unimelb.edu.au

     North America:
		Performance Peripherals
		fiset@globalone.net
		Peter Fiset

     Anywhere else:   Choose the nearest!


-- 

From: gardners@ist.flinders.edu.au (Paul M. Gardner-Stephen)
Subject: 64NET/2 aka 64NET/TCP aka NET-8
Date: 16 Jun 1995 01:09:27 GMT

Hi all!

Just a brief word on the front of the new version of 64NET which is almost
at the "RSN" stage.

The new version offers:

* Near 100% compatibility with all non fast-loading software
* Replacement kernel option
* Direct access to FTP and WWW through the ftp: and http: special partitions
* Divert upto 32 devices to the network
* *Real* printer diversion
* Improved file system
* New DOS which is near 100% compatible to CMD's HD-DOS(tm) to aid software
  compatibility.
* Ability to work over a modem and the internet! IE - if a site runs a 
  64NET/2 daemon you can have direct access to FTP as though it were a nice
  hard-disk on your desk (if a little lagged).
* 1541,1571,1581 Emulation partitions
* Various connection options (Swiftlink, bi-directional Parallel etc)

NOTE: The above details are subject to change, and are offered only as a
indication of the intentions of the software writers of 64NET.


Paul Gardner-Stephen,
-- 
+-------------------------------------------------------------------------+
|Paul Gardner-Stephen    USENET:        gardners@ist.flinders.edu.au      |
|                           BBS:        Fishbowl +61 8 2771361 v.42, 14k4 |
| 64NET Author	          Voice:        +61 8 2777479 +9:30 GMT           |
| C64 Coder               Snail:        1 Hurst St,Morphettville SA 5043  |
| Highlander/FairLight                  Australia.                        |
|                      IRC-Nick:        Highlandr                         |
| 3:633/272.2              Html:        down :(                           |
+-------------------------------------------------------------------------+


From: R.Alphey@agriculture.unimelb.edu.au (Russell J. Alphey)
Subject: Re: Compatibility of 64Net
Date: 16 Feb 1996 07:15:48 GMT


> I am considering using 64Net as a file server for a 64 and/or 128.  
>How compatible is 64Net?  Can you run most anything if you have the 

Very.  However, there was no cartridge version, per se.  There was to
be a replacement kernel version, but this has not been released.
This is due to a number of factors of varying severity -

1. The Swedish coders who were doing the kernel patches stopped working
   on it when it was nearly complete (AFAIK).
2. 64NET v2 will not require any wedge, patch, or replacement kernel.
   It was felt that it was hardly worthwhile finishing the kernel replacement.

>cartridge version?  That is the option that would interest me most.  I 
>have an old 8086 machine that is unused and basically worthless, but it 
>would serve a very nice function if I could use it as a file server for 
>the 64.

You can, because I have! :)

>        Also:  Is the X1541 cable the same as the 64Net cable?

Nope.  The current 64NET cable goes from the User Port on the 64/128 to the
PC's parallel (printer) port.  V2's cable will be *like* X1541's, but I don't
know whether it will be pin compatible.  Good question tho'!

64NET is shareware, so you can try it out with no obligation.  The latest
released version is 1.82.58 - email me for a copy!
 
------------------------------------------------------------
R.Alphey@agriculture.unimelb.edu.au      Ph +61-3-9344-8884
                                        Fax +61-3-9344-4007


From: Phil Hoff <phoff@ecst.csuchico.edu>

> I would like to use PC as a hard disk :)

64NET is reported to be able to do this. Download it from:
ccnga.uwaterloo.ca/pub/cbm/util64/DISK



From: ppieroni@ppse.win-uk.net (Chip Pieroni)
Date: Fri, 09 Feb 1996 21:48:02 GMT
Subject: Re: Hooking up a C-128 to a PC?

 
In article <xTFLBI7.cindysimms@delphi.com>, J. E. Sears (cindysimms@delphi.com) writes:
>Darkmoon <Darkmoon@sisna.com> writes:
> 
>>I was wondering if it is possible to hook up a C-128 to a PC running Win95?

        Certinally, all you have to do is run C64NET in a Maximized
or completely minimised DOS box and hey presto. DON'T try and print
and in the .PIF settings box mark 'Prevent DOS Applications from
detecting Windows' with a tick.

        I think that if you are using DRVSPACE then DOS would be a
better option, as C64NET gets right into low level disk access
that the Win 95' protection system sometimes doesn't like very much.
DOS V6 + (including 7 with Win 95') has no problems with that
(unless the program goes mega crazy with the disk, bad enough for
the BIOS to report a possible virus infestation.)

---
Chip Pieroni

Vintage Systems Finder


From: Pontus Berg <Bacchus@FairLight.COM>
Newsgroups: comp.emulators.cbm
Subject: Re: Idea for C64 diskimages
Date: Fri, 26 Jan 1996 10:50:26 -0800

Markus Peter wrote:

> : How about someone make a program so that your C64 hooks directly to your PC
> : via X1541 cable so that the PC can be a "fileserver" for the C64? Just have
> : fast and/or full emulation going to diskimages, where on the PC end you can
> : choose a diskimage and on the C64 end you treat the PC as a standard device 8
> : 1541/1571/1581? :) 
> Well... such a system already exists, for both Amiga and Pc. On PC it's
> called 64net, I think. Don't ask me though which name it got on Amiga.

Yes and no. 64NET is *NOT* working as a serial device! It is a "special device"
which uses the userport for the datatransfer, meaning you have to add a
"driver" in the  computer.
This means that you'd better have the routine in ROM or have it included in 
the programs you intend to use.

64NET does not exist on the Amiga. There are a few program trying to do this,
but they are very limited, at least the ones I've seen. Only load, save and
directory AFAIK. You need a working getbyte-routine in order to have programs
like TurboAssembler working OK!

-- 
[  o/  PBG@HK.Mobitel.Telia.SE   Bacchus@FairLight.COM         ]


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

  14. FURTHER READING

  14.1 VICE Documents

  The following documents come with the VICE:
	x64.{man,cat}		X64 manpage
	petcat.{man,cat}	petcat manpage
	recomment.doc		recomment manpage
	README			X64 installation guide
	README.RUN		x64run front-end guide
	Emulation		Details on the VICE and different file formats
	DIN_charset		DIN and ASCII charsets for serial printers
	Star.codes		Printer control code list
	serial.doc		CBM Serial Bus Protocol
	drive_info		CBM Disk Drives
	cbm_basic_tokens	BASIC token code list
	pal.timing		VIC-II timing revealed
	64doc			Extensive CPU documentation
	PETdoc			Some notes on the PET series
 

  14.2 Other Documents

  The files listed below are available via FTP on x2ftp.oulu.fi:/pub/cbm/
  and ftp.funet.fi:/pub/cbm/ if not stated otherwise.


   Memory
	All memory maps are at:
		     x2ftp.oulu.fi:/pub/cbm/maps/
		 and ftp.funet.fi:/pub/cbm/maps/

	c128-basic.diffs
	c128-kernel.diffs
	c64-kernel.diffs
	vic20-kernel.diffs

	c64.pla.equations
	c64.pla.functions

	32K Internal VIC-20 Memory expansion are located at
		ftp://x2ftp.oulu.fi:/pub/cbm/docs/VIC-32K-expansion

	Internal C64/C128 Memory expansions
		The comp.sys.cbm General FAQ
		ftp://ftp.funet.fi:/pub/cbm/documents/1028/
		ftp://ftp.funet.fi:/pub/cbm/documents/256kB/


   Video Timing
	pal.timing


   SID
	SID related documents:
		x2ftp.oulu.fi:/pub/cbm/docs/sid/
		http://stud1.tuwien.ac.at/~e9426444/sidtech.html


   Disk Drives
	Full 1541 manual  ftp.funet.fi:/pub/cbm/documents/oc-118.manual
	1541.tricks

   Printer
	DIN_charset
	Star.codes


   Miscellaneous
	cbm_basic_tokens
	csg.chips.info
	hidden_secrets



  14.3 FAQs

 For full collection of FAQs, visit rtfm.mit.edu or the nearest of its
 mirrors (e.g. ftp.sunet.se)

	comp.sys.cbm	    Commodore FTP Sites List
	comp.sys.cbm	    General FAQ
	comp.emulators.cbm  FAQ
	comp.emulators.misc FAQ
	comp.sys.sinclair   FAQ  (For Zilog Z80 info.)


 PC File formats FAQs
	x2ftp.oulu.fi:/pub/msdos/programming/formats/


 Character set and standard documents, converters, etc
	ftp.funet.fi:/pub/doc/charsets/
	modeemi.cs.tut.fi:/pub/suomalaiset_merkit.ps 


 (American) Copyright FAQ

 RTFM has reorganized some of its FTP directories, specifically the 
 law-related ones.  The following URLs will point to the current version 
 of the Copyright FAQ:

	ftp://ftp.netcom.com/pub/ca/carrollt/law/copyright/faq
	ftp://ftp.aimnet.com/pub/users/carroll/law/copyright/faq
	ftp://rtfm.mit.edu/pub/usenet/news.answers/law/copyright/faq



  14.4 FTP sites

    ftp.funet.fi /pub/cbm			Emulators, Programs, Docs
	From Sweden: use "ftp.funet.funic.fi" instead.

    frodo.hiof.no				Emulators
    ftp.giga.or.at				Tools
    arnold.hiof.no				Games
    ftp.armory.com /pub/user/spectre/EMULATION	Games
    bbs.cc.uniud.it				Games
    x2ftp.oulu.fi				Docs



  14.5 Internet Resources

  The VICE Emulator / Simulator For Unix
    http://stekt.oulu.fi/~jopi/vice.html
    http://www.tu-chemnitz.de/~fachat/vice/vice.html

  SID Emulation
    http://stud1.tuwien.ac.at/~e9426444/index.html


  Programming languages
    http://www.wimsey.com/~danf/cbm/languages.html

  6502 Cross-Development Languages and Tools
    http://www.wimsey.com/~danf/cbm/cross-development.html

  PC/Amiga Tools List
    http://www.ludd.luth.se/~watchman/fairlight/

  Free CBM Manuals Site
    http://ourworld.compuserve.com:80/homepages/pcgeek/

  The Commodore 64 WWW Server.
    (Has a few c64s and x64 documents)
    http://www.hut.fi/~msmakela/c64.html

  Commodore 64 computing  (Home of the comp.sys.cbm FAQ)
    http://www.msen.com/~brain/


  WWW Personal Computing and Emulation Homepage
    http://www.freeflight.com/fms/comp/
  Commodore emulation
    http://www.freeflight.com/fms/comp/Emulation/Commodore.html

  USENET FAQs (from rtfm.mit.edu)
    http://www.cis.ohio-state.edu/hypertext/faq/usenet/FAQ-List.html

  The Star Commander home page
    http://ludens.elte.hu/~sta/sc.html



  14.6 Commodore Manuals

	Commodore VIC=20 Programmers' Reference Manual
	Commodore 64 Programmers' Reference Manual
	Commodore 128 Programmers' Reference Manual



  15. ACKNOWLEDGEMENTS

  The Opcode section is based on
	The "64doc" file by
	    Marko Mkel	(msmakela@kruuna.helsinki.fi)
	    John West		(john@ucc.gu.uwa.edu.au)

	C=Lehti magazine 4/87,
	    article by Kai Lindfors and Topi Maurola

	Mnemonic lists from
	    C=Hacking net-magazine
	    "Commodore 64, Konekieli"
	    John West
	    Expose
	    Pure-byte

	News article by
	    Bruce McFarling	(brmcf@utkux1.utk.edu)

  Other CPU info by
	Chris Baird		(cjb@brushtail.hna.com.au)
	Angelo Campitelli	(eng-ac@jcu.edu.au)
	Jan Kuipers


  The Memory section
	C64 Kernel Differences description "c64-kernel-diffs"
	by Marko Makela and Peter Weighill

	Heiko R. Selber		(selber@FHI-Berlin.MPG.DE)
	Ulf Harnhammar		(uhaen92@hvdc.hv.se)
	--			(withers_n@kosmos.wcc.govt.nz)
	Rick Kephart		(rmk@netaxs.com)
	Roland Toegel		(toegelrd@tick.informatik.uni-stuttgart.de)
	Keevy McAlavy		(mcalavy@pioneer.nevada.edu)
	Thierry Lescot		(thierry.lescot@ping.be)
	Thomas Tavoly		(ttavoly@amiga.ow.nl),(ttavoly@cistron.nl)
	Raymond Carlsen		(rrcc@u.washington.edu)
	Seth Hopkinson		(hopkins@smartlink.net)
	Cameron Stewart		(1cs3783@tstc.edu)
	Bryan Pease		(bpease@erc.cat.syr.edu)
	Dan Fandrich		(dan@fch.wimsey.bc.ca)
	Jeremia Schouten	(skynetw@dds.nl)
	Pontus Berg		(Bacchus@FairLight.COM)
	Ivan			(firefoot@omni.voicenet.com)
	Alan Jones		(alan.jones@qcs.org)
	Bruce McFarling		(brmcf@utkux1.utk.edu)


  The CP/M section
	"Tips and Tricks for the C128"
		by Hornig, Weltner & Trapp

	Marat Fayzullin		(fms@freeflight.com)
	621126@mercury.utb.edu	(Mike Gordillo)
	Tracy Ratcliff		(tratclif@oucsace.cs.ohiou.edu)
	Marko Makela		(Marko.Makela@HUT.FI)
	George W. Taylor	(aa601@cfn.cs.dal.ca)
	Craig Bruce		(csbruce@ccnga.uwaterloo.ca)
	Dave Kennedy		(--)
	NEUS@timsg.csc.ti.com	(Mike Neus)
	Jim Stephenson		(stephenson11@delphi.com)
	Fuzzy Fox		(fox@netcom.com)



  The REU section
	Richard Hable		(hab@jk.uni-linz.ac.at)
	Steve Rohatynsky	(rohatyns@freenet.mb.ca)


  The I/O Port section
	"Mapping The Commodore 64" by Tim Arnot
	A book on the C128 whose name I've lost.  ):

	Andreas Boose		(boose@misa.extern.fh-hannover.de)
	Marc Schoenefeld	(schonef@uni-muenster.de)
	Pontus Berg		(PBG@HK.Mobitel.Telia.SE)


  The Serial Bus Peripherals section
	Brian Heyboer		(bjheyboer@space.honeywell.com)
	Robert J. Gonzalez	(gonzo@indirect.com)
	Jack Vander White	(ceejack@crl.com)


  The Locale section is based on
	The netiquette guide/FAQ "Suomalaiset merkit tietokoneissa" by
	    Timo Kiravuo	(kiravuo@hila.hut.fi)
	    Sami J. Mkinen	(sjm@cs.tut.fi)

	Star LC 10 CCL Printer User's Manual
	Commodore MPS 803 Printer User's Manual

	Character set descriptions by
	    Pekka Pessi		(Pekka.Pessi@hut.fi)
	    Richard Hable	(hab@jk.uni-linz.ac.at)

	and news articles written by
	John F Davis		(aa122@detroit.freenet.org)


  The Compatibility section is based on the information acquired from
	The comp.emulators.cbm FAQ
	The comp.sys.cbm General FAQ
	Normal and raw D64 format descriptions by Miha Peternel
	The book "Commodore 64, Levyasema"
	and news articles written by
	    David Ashley	(dash@netcom.com)
	    Guntram Blohm	(blohm@mathematik.uni-ulm.de)
	    Kevin Brisley	(kbrisley@tsegw.tse.com)
	    Kimmo Veijalainen	(veijalai@liero.cc.lut.fi)
	    Michael Schwendt	(3schwend@rzdspc63.informatik.uni-hamburg.de)
	    Bruce Gingery	(bruce@TotSysSoft.com)
	GEOS section
	    Peter Schepers	(schepers@dcs1.uwaterloo.ca)
	    Andreas Varga	(e9426444@stud1.tuwien.ac.at)
	    Peter Karlsson	(m9944@abc.se)


   The Programming / Program Conversions section:

	Olaf Seibert		(rhialto@mbfys.kun.nl)
	Cameron Kaiser		(ckaiser@ucsd.edu)
	Joe Pylka		(PYLKA@PHOENIX.PRINCETON.EDU),
				(72345.1601@CompuServe.COM)
	Chris Milton		(cmilton@access.digex.net)
	Chris McCormack		(chrismc@eecs.umich.edu)
	Jack Vanderwhite	(Jack.Vanderwhite@cee-64.gigo.com)
	Bruce McFarling		(brmcf@utkux1.utk.edu)
	Dave Belter		(dbelter@delphi.com)
	Steve Rohatynsky	(rohatyns@freenet.mb.ca)
	James Chamblin		(jamesch@ix.netcom.com)
	Myles B. Williams	(williams@UTKUX1.utk.edu),(mwilliam@duncan.cs.utk.edu)
	Mike Neus		(bogus)
	Heiko Selber		(selber@fhi-berlin.mpg.de)
	Phil Hoff		(phoff@ecst.csuchico.edu)
	R. T. Cunningham	(wanderer@indirect.com)


  The File Conversion and Transfer sections are based on
	The comp.emulators.cbm FAQ
	PDA WWW Page (http://www.cfn.cs.dal.ca/Services/PDA/commodore.html)
	Documents for some of the programs described

    and news articles written by
	Kevin Brisley		(kbrisley@tsegw.tse.com)
	Tree Pig		(treepig@mail.utexas.edu)
	Roemisch Volker		(i275@stio1.sari.fh-wuerzburg.de)
	Chris McCormack		(chrismc@eecs.umich.edu)
	Larry T. Williams	(lwilliam@pioneer.arc.nasa.gov)
	Tony Cianfaglione	(ab616@cfn.cs.dal.ca)
	Wolfgang Lorenz		(100112.220@CompuServe.COM)
	Mikko Vuorinen		(vuorinen@cc.lut.fi)
	Anni O Selin		(aselin@cc.helsinki.fi)
	Sami J Laine		(oh1jkt@mea.utu.fi)
	Jarkko Kemppainen	(mysti@stekt.oulu.fi)
	Brad Garcia		(garcia@erie.ge.com)
	Antti Piirainen		(piiraine@mopo.cc.lut.fi)
	Scott Hagie		(hagie@netcom.com)
	---			(TJOE1@delphi.com)
	Johnathon Suker		(jlsuker@uci.edu)
	Per Einarsson		(c94perei@ida.liu.se)
	Tonks D			(fira76%teach@dcs.shef.ac.uk)
	Don Parker		(don.parker@jadecat.com)
	David W. Tamkin		(dattier@MCS.COM)
	Olaf Seibert		(rhialto@mbfys.kun.nl)
	Russell Alphey		(R.Alphey@agriculture.unimelb.edu.au)
	Jean P Nance		(jpnan@prairienet.org)
	Bernhard Schwall	(schwall@athene.informatik.uni-bonn.de)
	Marko Makela		(Marko.Makela@HUT.FI)
	Jim Rowell		(jim.rowell@canrem.com)
	Rick Mosdell		(rick.mosdell@canrem.com)
	Patrick Fleming		(wiz@apple.com)
	Perry Eidelbus		(pbeast@stellar.comnet.com)
	Stephen Judd		(judd@merle.acns.nwu.edu)
	Todd S. Elliott		(tselliot@gate.net)
	Aaron J. Baugher	(abaugher@worf.netins.net)
	Tom Hoot		(thoot@starbase.neosoft.com)
	Bruce McFarling		(brmcf@utkux1.utk.edu)
	WaD			(wad3@indy.net)
	Henrik Isacsson		(Snout@Furry.ct.se)
	David Belter		(dbelter@delphi.com)
	Jyrki Sarkkinen		(jyrkis@paju.oulu.fi)
	Peter F Kurek		(PFKUREK@frost.oit.umass.edu)
	Craig Bruce		(csbruce@ccnga.uwaterloo.ca)
	Alan Jones		(alan.jones@qcs.org)
	Arndt Dettke		(057184449-0001@btxgate.de)
	toast			(toast@primenet.com)
	Roland Toegel		(toegelrd@track.informatik.uni-stuttgart.de)
	John M. Williams	(theenforcer@delphi.com)
	Paul Fisher		(paul.fisher@ferrari.ct.se)
	R. Akins		(cynrcr@delphi.com)
	John Iannetta		(76703.4244@CompuServe.COM)
	Michael Bendure		(mbendure@infinet.com)
	Michael Parson		(mparson@io.com)
	Ivan			(firefoot@netaxs.com)
	Chris Scudder		(lscudder@ic.sunysb.edu)
	Frederick Barnett	(fred8615@delphi.com)
	Patrick Vaculin		(pvaculin@xmission.com)
	E.W.C. de Vos		(vos@dutiws.twi.tudelft.nl)
	Tom Bradley		(t.bradley@ge.ic.ac.uk)
	Peter Schepers		(schepers@dcs1.uwaterloo.ca)
	Rick Kephart		(rmk@unix2.netaxs.com)
	Stefan Froehlich	(e9025800@stud1.tuwien.ac.at)
	Joe Forster		(sta@ludens.elte.hu)
	Luis Hernandez		(louhern@symnet.net)
	Donald Chin		(donaldc@werple.apana.org.au)
	Mike Neus		(NEUS@timsg.csc.ti.com)
	David G. Slomin		(dgslomin@princeton.edu)
	Paul M. Gardner-Stephen	(gardners@ist.flinders.edu.au)
	T.A.Rahim		(u9411127@muss.cis.McMaster.CA)
	Tuomas Paasiala		(tuoppi@spider.compart.fi)
	Maxwell Daymon		(mdaymon@rmii.com)
	Howard Herman		(72560.3467@CompuServe.COM),
				(aa349@cleveland.Freenet.Edu)
	Bod			(darren@talent.demon.co.uk)
	David Gahris		(dgahris@eece.maine.edu)
	Kevin Horton		(khorton@tech.iupui.edu)
	Sy Ali			(Sy.Ali@canada.tor250.org)
	Paul Fisher		(paul.fisher@ferrari.ct.se)
	Nathan Kresse		(nkresse@on-ramp.ior.com)
	Darrin Smith		(darrins@cyllene.uwa.edu.au)
	Pontus Berg		(Pontus.Berg@p71.anet.canit.se),
	                        (PBG@HK.Mobitel.Telia.SE  or
				 Bacchus@FairLight.COM)
	Loon			(i942299@redgum.bendigo.latrobe.edu.au)
	Mike Luznicky		(we4@widomaker.com)
	Edward C. Shaw		(edshaw@iglou.com)
	Evan			(msalomon@ccnet.com)
	John F Davis		(aa122@detroit.freenet.org)
	Per Olofsson		(MagerValp@Goth.Org)
	Linus Walleij		(triad@df.lth.se)
	Jeremia Schouten	(skynetw@dds.nl)
	William R. Ward		(hermit@cats.UCSC.EDU)
	Jezebel Rebecca Delilah	(jezzydee@clam.rutgers.edu)
	Paul Lieberman		(discon@news.dorsai.org)
	Bo			(ez13942@nyssa.swt.edu)
	K E W Thacker		(K.E.W.Thacker@cs.cf.ac.uk)
	Ruben Spaans		(scroll@nordnett.no)
	Leopoldo Ghielmetti	(Leopoldo.Ghielmetti@epfl.ch)
	Chris Abbott		(abbottc@delphi.com)
	ChrisC			(jamesch@popd.ix.netcom.com)
	George Brock-Nannestad	(koskphon@inet.uni-c.dk)
	Gerhard Wesp		(gwesp@cosy.sbg.ac.at)
	Cris Berneburg		(74171.2136@compuserve.com)
	Christian Wolf		(Christian.Wolf@Informatik.Uni-Oldenburg.DE)
	Chris Gioconda		(cyberbyte1@pb.net)
	Jacob Gorny		(gornyja@whitman.edu>
	Mark Perrego		(perregom@delphi.com>
	Phil Hoff		(phoff@ecst.csuchico.edu>
	Phil Porth		(pdporth@freenet.calgary.ab.ca>
	Dan Fandrich		(dan@fch.wimsey.bc.ca)
	David M. Williams	(dave@maths.newcastle.edu.au)
	Predi			(e9325492@stud1.tuwien.ac.at)
	Jeremy Ouellette	(gt6010a@acmex.gatech.edu)
	Guenther Bauer		(h9101322@falbala.wu-wien.ac.at)
	Ismael Cordeiro		(ismael@CAM.ORG)
	John Halloran		(jfh@snet.net)
	Christian Janoff	(mepk@hp67.rbg.informatik.th-darmstadt.de)
	Peter LaDow		(pladow@cad341.intel.com)
	Patrick Leung		(pleung@cs.buffalo.edu)
	Ronald Varnum		(ronv@iglou2.iglou.com)
	Walter Zimmer		(s_wzimme@panther.rz.uni-ulm.de)
	Il grande Fool		(ulrich.steppberger@public.uni-augsburg.de)
	Post Office Clerk	(PostMan@jedi-server)
	Yvo Nelemans		(nelemans@ct.utwente.nl)
	Chip Pieroni		(ppieroni@ppse.win-uk.net)


  Resources section
	Terry Carroll		(carrollt@netcom.com),(carroll@aimnet.com)
