-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy pathREADME
221 lines (159 loc) · 7.02 KB
/
README
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
XD-2031 - Serial line filesystem server for CBMs
------------------------------------------------
V0.9.x, Feb 2022
NOTE: This software is in the middle of a re-org. Wear your hard hat
This software enables to program an AVR AtMega device to play
the role of a disk drive to a Commodore PET computer with IEEE488
interface, a disk drive for the serial-IEC-based machines like
the C64, the C128 and others.
XD-2031 consists of two main parts, an AtMega firmware, and a PC server.
Both communicate via a serial line.
Currently this hardware is supported:
- XS-1541 Communication via serial line over USB
- petSD Communication via serial line over USB
- petSD2 Communication via serial line over USB
For more information see the README files in the subdirectories
Building
--------
To build the firmware image, see the README file in the firmware directory.
To build the server side code, see the README file in the pcserver directory.
Testing
-------
To build the tests, simply run "make tests" in this directory.
Please note that the (growing) number of tests has some that fail - that
is partly due to sampling test data from a CBM DOS, that is buggy itself
(like the blkaf1/blkaf2 tests do not allocate blocks on disk on the 4040
emulation...)
Using
-----
To use the PC as disk drive, the Commodore must be connected to one
of the supported devices running the firmware part. This device must
be connected to the PC, usually with a serial-over-USB connection.
The server can then be configured with some command line options:
-d <devicepath>
path to the serial device where the server communicates
with the firmware
-A<drv>:<provider-string>
This "assign" command allows defining what is behind
a "drive" in Commodore terms. The code allows for using
ten different drive numbers (as opposed to the common
two), so you can have drive numbers 0-9.
The provider-string is special in that it defined what
is then used as drive content. It consists of a provider
name, and a parameter string for the provider.
A provider can be "fs" for the local file system,
"tcp" for a TCP/IP connection, or "ftp" or "http" for
their respective protocols. Here are examples and
descriptions of their parameters:
fs=<directory-path>
assigns a local directory to a drive
tcp=<hostname>
assigns a host name to a drive, any OPEN
then opens the port given as OPEN file name
ftp=<hostname>[/<path>]
http=<hostname>[/<path>]
assigns an FTP or HTTP path to the drive.
Only FTP supports reading a directory though.
-X<bus>:<cmd>
send an 'X'-command to the specified bus, e.g. to set
the IEC bus to device number 9 use:
-Xiec:U=9
"<bus>" can normally be "iec" or "ieee" (or "sock488" for the
socket-based test version of the firmware".
Another interesting commands are
-X<bus>:*=+
enable the use of advanced wildcards
-X<bus>:*=-
disable the use of advanced wildcards
-X<bus>:E=-
-X<bus>:E=+
disable/enable the drive number if the channel 15
error messages, also restrict number of
digits for track and sector to two
-XR
Reset the device
If the device as non-volatile configuration memory, these commands
are also available:
-XI
restore default values from NV-RAM
-XW
write configuration to NV-RAM
Please note that you can use the X and A commands also on the command channel, from the
Commodore machine side.
OPEN15,8,15,"A9:fs=foodir"
or
PRINT#15,"XU=9"
You can leave out the bus here, as the command is given to the bus that receives the
command.
Notes
-----
- With the XS1541 hardware all hardware attached to the device on the bus
you want to use must be switched on on reset. I.e. if you want to use the
IEEE bus, all IEEE devices must be switched on, the same holds for the IEC
bus. You can switch on the devices on the other bus later, but if you switch
a device off, the device hangs. This is due to the switched off devices
pulling down the ATN line, blocking the XS1541
Copyright
---------
The code is under GPL V2. Please note that the PC server part is
also available on later versions of the GPL, the AtMega firmware is
ONLY(!) available under GPL V2.
(C) 2012,2014 Andre Fachat <[email protected]>,
Ingo Korb, Thomas Winkler, Nils Eilers and others!
Please see the individual files for specific copyright notices.
ROADMAP
--------
Here are some ideas about what can be implemented. For and more current
information see also the github issues list on:
https://github.com/fachat/XD2031/issues?state=open
Planned features for Release 1.0
--------------------------------
- direct channel support (U1/U2 commands)
-> done
- SD card provider on the atmega side
-> started
- D64 support on the server side, to be able to use D64/D80/D82 etc files
-> done
- IEC support so C64 et al can use the device
-> done for C64, done for C128,
and VIC20 still to test
- Use other providers without ASSIGN before, e.g. LOAD"sd:filename",8
-> done (for http/ftp/tcp)
- bidirectional file support, together with TELNET functionality
-> done
- store configuration parameters in EEPROM
-> beta
- set configuration parameters from the PC
-> done
- and various other small improvements
Further plans
-------------
With the ASSIGN command it is possible to assign drive numbers (like the "0" in "$0")
to different service providers. Some of those will be in the atmega, some will be on the PC side.
Currently there is only one in the atmega, the one that connects via RS232-over-USB. On the PC
side there currently are five, filesystem, disk images, plain TCP as well as FTP and HTTP.
All those providers basically implement the "wireformat" protocol, so it is a clearly separated
responsibility. If you are willing to help with one of these ideas, feel free to contact me!
In the future these providers can be implemented:
- A D64 provider on the atmega side, to use D64/D80/D82 etc files from the SD card
- An iec provider - so a PET can "call out" to a serial IEC floppy
- And vice versa, an ieee provider and a serial iec bus interface to
allow e.g. the C64 to use an IEEE488 disk
- A remote FS provider on the PC side: connect to a remote "wireformat" server
On the XS1541 I'm actually willing to sacrifice the parallel user port connector (for C64 fastloaders)
in favour of a device number switch, an SD card interface, and maybe a serial configuration PROM.
Further ideas:
- support a non-parallel fast loader for the C64 (e.g. Jiffy-DOS?)
- M-R/W feature to mimic existing drives (to fool copy programs,
possibly change unit address via M-W)
REFERENCES
----------
XS-1541: The hardware by T. Winkler is described here:
http://xd2031.petsd.net/xs1541.php
petSD: The hardware by N. Eilers is described here:
http://petsd.net
sd2iec: Some files in this firmware are derived from the sd2iec project by I. Korb
http://www.c64-wiki.com/index.php/sd2iec_%28firmware%29
cURL: The cURL library is used to implement internet communication, esp.
the HTTP and FTP protocols. You can find it at
http://curl.haxx.se/