/[projet1]/public/pc/tools/osdk/main/makedisk/disk_infos.txt
Defence Force logotype

Contents of /public/pc/tools/osdk/main/makedisk/disk_infos.txt

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1022 - (show annotations)
Sat Dec 14 17:31:43 2013 UTC (5 years, 11 months ago) by dbug
File MIME type: text/plain
File size: 42976 byte(s)
FloppyBuilder 0.7
- The code now automatically compute the gaps values based on the floppy structure parameters
- The 'DefineDisk' command now works (at least for 2 sided, 42 tracks and 17 sectors floppies)
1
2 /*
3
4 Technical infos about Oric discs and FDC:
5
6 The FDC controller can cope with 128, 256, 512 and 1024-bytes sectors. Then it's a matter of programming...
7 The sector read/write routines of OricDos/Sedoric/Stratsed already are 512-bytes-sector compatible...
8 Loading a single 512-bytes sector is faster than loading two 256-bytes sectors, and you can safely store nine 512-bytes sectors on a double density disk track, whilst storing eighteen 256-bytes sectors with Stratsed has always brought problems...
9
10 Things to check: Fantasmagoric boot sector
11
12 Both the microdisc controller and the jasmin controller have electronics to control the MAP and ROMDIS signals on the expansion port. This allows them to switch between the BASIC rom, the overlay ram, and an eprom that reads the OS from the floppy disk.
13 As you said, a difference between the microdisc and the jasmin is that at startup, the jasmin electronics lets the Basic rom active. When you press the button, it causes a reset of the CPU (this doesn't reset the ram contents!), and simultaneously the jasmin eprom is made active, and so the eprom reads the boot sector (first sector, track 0), and executes this boot sector.
14
15 Of course, the disc structure is different from the Sedoric one, and even from the OricDos one, but Jasmin and Microdisc discs have the same sector size (256 bytes) and thus can be read on both, sector by sector.
16
17
18 So, I guess it is possible to do a Jasmin and Microdisc compatible disc ?
19 What about this structure:
20 - Track 0/sector 1: a Jasmin bootsector
21 - Track 0/sector 2: a Microdisc bootsector (BOOTUP.COM)
22 - Track 0/sector 3: a fake Oric dos directory to run BOOTUP.COM
23
24 The most annoying thing is to respect the OricDos format imposed by the microdisc eprom (the eprom indeed contains a truncated version of OricDos 0.6).
25 OricDos format has obliged the other operating systems to fake a mini-OricDos filesystem at the beginning of the disk. Normally you need at least 3 sectors, but by tweaking a little, you can have all three sectors in a single one, this is what I do in the Fantasmagoric boot sector...
26
27
28
29 a) Une piste SEDORIC est formée de 16, 17, 18 ou 19 secteurs de 256 octets. Entre ces secteurs de data
30 proprement dits, se trouvent des "gaps" qui contiennent des informations utiles pour le contrôleur de
31 lecteur.
32
33 b) Le début d'une piste (facultatif) commence par une série de 80 [#4E], 12 [#00], [#C2 #C2 #C2 #FC],
34 puis par une série de 50 [#4E] (selon la norme IBM) ou 40 [#4E], 12 [#00], [#C2 #C2 #C2 #FC] et 40
35 [#4E] (SEDORIC, si 16 ou 17 secteurs par piste, sinon rien), soit une économie de 50 à 146 octets.
36
37 c) Chaque secteur est alors précédé d'un champ d'identification formé de: 12 [#00], la séquence de
38 synchronisation [#A1 #A1 #A1], [#FE pp ff ss tt CRC CRC] puis 22 octets [#4E]. Le champ de data est
39 constitué de 12 octets [#00], la séquence de synchronisation [#A1 #A1 #A1], le marqueur de début de data
40 [#FB] et enfin les 256 octets du secteur. Chaque secteur est suivi de 80 octets [#4E] (selon la norme IBM
41 et 40, 30 ou 12 octets [#4E] dans le cas de SEDORIC, selon le nombre de secteurs par piste), soit une
42 économie de 12 à 42 octets par secteurs. Puis vient le secteur suivant... (NB: #pp = n(piste, #ff = n(face,
43 #ss = n(secteur, #tt = taille (#01 pour les 256 octets de SEDORIC, #02 pour les 512 octets de l'IBM PC
44 etc...)
45
46 d) La fin de piste est marquée par un nombre très variable d'octets [#4E] (facultatif). La piste étant
47 circulaire, toutes les valeurs entre la fin de piste et le début de piste sont sans signification
48
49 e) Selon le nombre de secteurs par piste, la place disponible pour les "gaps" est variable. Toutes ces
50 indications sont théoriques, lorsqu'on lit une piste et ses "gaps" avec un utilitaire spécialisé tel que
51 NIBBLE, on obtient des différences. Le premier des 3 octets de synchronisation par exemple est toujours
52 faux, puisque la synchronisation n'a pas encore été obtenue! De plus, la zone située entre la fin des data
53 et les octets de synchronisation de l'en-tête du secteur suivant (soit le "gap" situé entre deux secteurs)
54 contient souvent n'importe quoi. En fait, ni le contrôleur de drive, ni le drive lui-même, ne répondent
55 instantanément. Il s'ensuit des bavures lors des changements d'état de la tête de lecture/écriture. C'est la
56 raison d'être de ces "gaps", qui servent à protéger le secteur suivant. Si l'on voulait augmenter le nombre
57 de secteurs par piste, il faudrait diminuer la taille des "gaps" et donc la fiabilité.
58
59 Soit en résumé:
60 Début de la piste (facultatif): 80 [#4E], 12 [#00], [#C2 #C2 #C2 #FC] et 50 [#4E] (soit 146 octets selon
61 la norme IBM) ou 40 [#4E], 12 [#00], [#C2 #C2 #C2 #FC] et 40 [#4E] (soit 96 octets pour SEDORIC).
62 Pour chaque secteur: 12 [#00], 3 [#A1] [#FE #pp #ff #ss #tt CRC], 22 [#4E], 12 [#00], 3 [#A1], [#FB],
63 les 512 octets, [CRC CRC], 80 octets [#4E] (#tt = #02) (soit 141 + 512 = 653 octets selon la norme IBM)
64 ou 12 [#00], 3 [#A1] [#FE #pp #ff #ss #01 CRC CRC], 22 [#4E], 12 [#00], 3 [#A1], [#FB], les 256
65 octets, [CRC CRC], 12, 30 ou 40 octets [#4E] (selon le nombre de secteurs/piste). Soit environ 256 + (72
66 à 100) = 328 à 356 octets pour SEDORIC.
67
68 Fin de la piste (facultatif): un nombre variable d'octets [#4E
69
70 Selon NIBBLE,
71 une piste IBM compte 146 octets de début de piste + 9 secteurs de 653 octets + 257 octets de fin de piste = 6280 octets.
72 Une piste SEDORIC, formatée à 17 secteurs, compte 96 octets de début de piste + 17 secteurs de 358 octets + 98 octets de fin de piste = 6280 octets.
73 Une piste SEDORIC, formatée à 19 secteurs, compte 0 octet de début de piste + 19 secteurs de 328 octets + 48 octets de fin de piste = 6280 octets.
74 On comprend mieux le manque de fiabilité du formatage en 19 secteurs/piste dû à la faible largeur des zones de sécurité (12 [#4E] entre chaque secteur et 48 octets entre le dernier et le premier).
75
76 Lors de l'élaboration du tampon de formatage SEDORIC, les octets #C2 sont remplacés par des octets
77 #F6, les octets #A1 sont remplacés par des octets #F5 et chaque paire de 2 octets [CRC CRC] et
78 remplacée par un octet #F7. Comme on le voit, nombre de variantes sont utilisées, sauf la zone 22 [#4E],
79 12 [#00], 3 [#A1] qui est strictement obligatoire.
80
81 // From DskTool:
82 15, 16 or 17 sectors: gap1=72; gap2=34; gap3=50;
83 18 sectors: gap1=12; gap2=34; gap3=46;
84
85
86
87
88 Fantasmagoric boot sector (Fabrice Frances)
89 -------------------------------------------
90
91 org $9fd0-11 ; this allows load_addr to be in $9fd0, see below
92
93 page1
94 ; first page of the Fantasmagoric boot sector, containing :
95 ; - Microdisc and Cumana "boot" sector (system parameters)
96 ; - OricDos directory
97 ; - OricDos and Cumana "system", in record format
98
99 off_00 db 40 ; Microdisc wants this to be not null (# of tracks)
100 ; this is also used as the track of the next directory sector
101 ; and also the track of the next sector of the loaded file
102 off_01 db 0 ; next directory sector, and also next sector of file
103 ; a 0 value means no next sector
104 off_02 db 1 ; only one entry in this directory
105 off_03 db 0 ; skip this directory entry (things are too intricated here)
106 ; record header
107 off_04 dw load_addr ; where to load this record
108 off_06 dw last
109 off_08 dw 0 ; this should be the exec addr, but it is copied elsewhere and
110 ; gets overriden by second page of the sector
111 off_0A db LOW(last)-LOW(load_addr) ; record size
112
113 load_addr ; load_addr=$9fd0, thus the copyright message starts now (empty)
114
115 ; Bios Parameter Block for the PC starts here but MSDOS and Windows don't seem
116 ; to use it anymore, and seem to rely on the type byte found in the FAT
117 off_0B db 0 ; microdisc copyright message is copied from here to the status line
118 off_0C db 0
119 off_0D db 0 ; cumana copyright message is copied from here to the status line
120 off_0E dw 0
121 off_10 db 0,0 ; OricDos parameters : first free sector location, but copied to the second part
122 off_12 db 1 ; OricDos parameters : directory sector #
123 off_13 db 0 ; OricDos parameters : directory track #
124 ; OricDos directory : 0 means skip this directory entry (things are way too intricated here !)
125 off_14 dw 0 ; OricDos parameters : # of free sectors, copied to the second part
126 off_16 dw 1 ; OricDos parameters : # of used sectors, copied to the second part
127 off_18 dw 0
128 off_1A dw 0
129
130 ; definition tables for floppy types 720KB, 180KB, 360KB
131 ; a third table (dataside) use the OricDos directory entry just below
132 dirsect db 8,6,6
133 datasect db 6,1,4
134 db 0
135 ; here we are more comfortable to store an OricDos directory entry
136 off_23 string "Boot 3.0"
137 dataside ; this saves some place since table is 1,0,1
138 db 1 ; BOOT is 1 sector
139 db 0,1 ; it starts at track 0 sector 1
140 db 0,1 ; so it ends at same sector
141 db 0,$80 ; flags
142
143
144 page equ $40 ; temporary variables in page 0
145 nbsect equ $41
146 addrbuf equ $42
147 addrbufh equ $43
148 sector equ $44
149 side equ $45
150 type equ $46
151 fdc_offset equ $47
152 machine_type equ 0
153 tmp equ 1
154
155 ; definitions
156 buf equ $A200
157 FDC_command equ $0300
158 FDC_status equ $0300
159 FDC_track equ $0301
160 FDC_sector equ $0302
161 FDC_data equ $0303
162
163
164 ; let's start some code at last
165
166 microdisc_start
167 sei
168 ldx #0
169 microdisc_move ; copy the second part of the sector
170 lda $C123,x ; which has not been transfered by the eprom code
171 sta page2,x
172 inx
173 bne microdisc_move
174 lda #$40
175 sta machine_type ; flag a microdisc controller
176 ldx #$10
177 stx fdc_offset
178 lda #$84
179 sta $0314 ; switch to overlay ram, disables FDC interrupts
180
181 all_start ; here is the common code for all machine types
182 lda #$7F
183 sta $030E ; disables VIA interrupts
184 ldx #2 ; first FAT sector
185 stx sector
186 lda #0
187 sta side
188 jsr buf_readsect ; get it in buffer
189
190 lda buf ; floppy type
191 sec
192 sbc #$F9
193 beq *+4
194 sbc #2
195 sta type ; now we have types 0 (720KB), 1 (180KB) , 2 (360KB)
196 tax
197
198 jsr search_system
199
200 lda buf+$1C,x ; compute the number of sectors used, minus 1 (the first one)
201 sec
202 sbc #1
203 lda buf+$1D,x
204 sbc #0
205 lsr a
206 sta nbsect
207
208 ; get the location of the first data sector
209 ldx type
210 lda datasect,x
211 sta sector
212 lda dataside,x
213 sta side
214 bne loadfirst
215 jsr step_in ; if it's on side 0 (180KB floppy), it's on track 1
216
217 loadfirst ; load first data sector
218 jsr buf_readsect
219
220 sec ; initialize transfer address
221 lda buf+1
222 sbc #5
223 sta addrbuf
224 lda buf+2
225 sbc #0
226 sta addrbufh
227 sta page
228
229 ldy #5 ; and transfer the first sector (except first 5 bytes)
230 ldx #2
231 moveloop
232 lda buf,y
233 sta (addrbuf),y
234 iny
235 bne moveloop
236 inc addrbufh
237 inc moveloop+2
238 dex
239 bne moveloop
240
241 nextsect ; compute next sector
242 ldx sector
243 inx
244 cpx #10 ; # of sectors per track
245 bne readnext
246 inc side
247 ldx type
248 lda dataside,x ; 1 if double-sided disk, 0 if single_sided
249 cmp side
250 bcs readnext
251 jsr step_in
252 ldx #0
253 stx side
254 inx
255
256 readnext ; read next sector
257 stx sector
258 inc page
259 inc page
260 try
261 lda page
262 sta addrbufh
263 jsr readsect
264 bne try
265
266 dec nbsect
267 bne nextsect
268
269 lda machine_type
270 jmp (buf+3) ; start the system
271
272 last db 0
273
274
275 ; second part (offsets $100-$1ff) of the fantasmagoric boot sector, this contains :
276 ; - boot for Telestrat
277 ; - boot for Jasmin
278 ; - values overriding Microdisc and Cumana variables due to a sector too big
279
280 org page1+$100 ; we are at offset $100 from the beginning
281 page2
282
283 ; Jasmin loads the boot sector in $0400, Telestrat loads it in $C100.
284 ; both Telestrat and Jasmin override first page of the sector with second page.
285 ; Jasmin starts exec at offset 0,
286 ; Telestrat has a five byte header and starts exec at offset 5.
287
288 db 0 ; Telestrat needs 0 at offset 0 for a bootable disk
289 ; Microdisc system parameter copy : first free sector being 0 means no sector (lucky me)
290 ; Jasmin interprets this instruction as BRK #9, hopefully no harm is done
291 db 9 ; Telestrat : # of sectors per track
292 ; Microdisc system parameter copy : track # of the first free sector (none, see above)
293 db 1 ; Telestrat takes here the number of sectors of the DOS to load
294 ; Microdisc system parameter copy : directory sector (lucky again)
295 ; Jasmin interprets this instruction as ORA (00,X), again no harm is done
296 db 0 ; Telestrat : LSB of DOS loading address, one dummy sector will be read there only
297 ; Microdisc system parameter copy : directory sector (lucky again)
298 db $2C
299 ; Telestrat : MSB of DOS loading address, chosen for the Jasmin usage below
300 ; Jasmin interprets this instruction as a BIT nnnn so it skips the following instruction
301 ; Microdisc system parameter copy : LSB of # of free sectors (can't be always lucky)
302 beq telestrat_start
303 ; flag Z is set when the telestrat does JSR $C105
304 ; Microdisc system parameter copy of # of free and used sectors are wrong, hard to do better
305 beq jasmin_start
306 ; at last we can take control on the Jasmin
307
308 off_109 string "Boot 3.0" ; this matching pattern overrides the one at $C12C on Microdisc
309 ; Cumana cannot use a matching pattern with wildcards here
310 reserve 6 ; this space could be used for my local variables in the future
311 off_118 db 0 ; this byte ($C12B) on the microdisc is copied to $C000
312 db $FF
313 reserve 2 ; this space could be used for my local variables in the future
314 off_11C db 0 ; this byte ($C13F) on the microdisc is tested against 0
315 reserve 11 ; this space could be used for my local variables in the future
316 off_128 dw microdisc_start ; this word ($C14B) is used as exec addr for microdisc
317 off_12A dw microdisc_start ; this word ($C14D) is used as exec addr for cumana
318
319 jasmin_start
320 sta $03FB ; 0->ROMDIS selects ROM
321 bit $FFFC
322 bmi atmos
323 jsr $F888
324 bne *+5
325 atmos jsr $F8B8
326 ldy #1
327 sty $03FA ; 1->ORMA selects overlay ram
328 lda #4 ; we are curently running in page 4
329 sta readboot_jsr+2-page2+$0400 ; so, adjust the JSR address
330 ldy #$20 ; flag a Jasmin controller
331 ldx #$F4 ; FDC location in page 3
332 bne half_sector_only
333
334 telestrat_start
335 lda #$7F
336 sta $032E ; disable VIA2 interrupts
337 sta $031D ; disable ACIA interrupts too
338 lda $031D ; clear ACIA interrupt in case...
339
340 ldy #$C0 ; flag Telestrat hardware and Microdisc hardware
341 ldx #$10 ; FDC location in page 3
342
343 half_sector_only ; load the full boot sector, we only have one half for now !
344 sei
345 sty machine_type
346 stx fdc_offset
347 ldx #1 ; sector 1
348 stx sector
349 dex
350 stx side ; side 0
351
352 reloadboot
353 ldy #LOW(page1)
354 lda #HIGH(page1)
355 sty addrbuf
356 sta addrbufh
357 readboot_jsr
358 jsr readsect-page2+$C100 ; the routine is not in its final location yet, so...
359 bne reloadboot
360 jmp all_start
361
362 buf_readsect ; read a sector in my buffer
363 ldy #LOW(buf)
364 sty addrbuf
365 lda #HIGH(buf)
366 sta addrbufh
367 jsr readsect
368 bne buf_readsect ; minimal error handling, retry forever until it works
369 rts
370
371
372 readsect
373 ldx fdc_offset
374 lda side
375 bit machine_type
376 bvc select_side
377 asl a
378 asl a
379 asl a
380 asl a
381 ora #$84
382 select_side
383 sta $0304,x
384 lda sector
385 sta FDC_sector,x
386 lda #$84
387 bne command
388
389 step_in
390 ldx fdc_offset
391 lda #$5B
392
393 command
394 sta FDC_command,x
395 ldy #4
396 dey
397 bne *-1
398 beq wait_command_end
399
400 get_data
401 lda FDC_data,x
402 sta (addrbuf),y
403 iny
404 bne wait_command_end
405 inc addrbufh
406 wait_command_end
407 lda FDC_status,x
408 and #3
409 lsr a
410 bne get_data
411 bcs wait_command_end
412 lda FDC_status,x
413 and #$1C
414 rts
415
416 search_system
417 lda dirsect,x ; get the first directory sector
418 sta sector
419
420 jsr buf_readsect
421
422
423 ldy #11
424 compare_name
425 lda buf,x
426 cmp dos_name,y
427 bne next_name
428 dex
429 dey
430 bpl compare_name
431 iny
432 beq found_name
433 rts
434
435 cluster_to_physical
436 ldx #$ff
437 compute_cylinder
438 inx
439 sec
440 sbc __sectors_per_cyl
441 bcs compute_cylinder
442 dey
443 bpl compute_cylinder
444 adc __sectors_per_cyl
445
446 stx __cylinder
447 ldy #0
448 cmp __sectors_per_track
449 bcc store_side
450 iny
451 sbc __sectors_per_track
452 store_side
453 sty __side
454 tay
455 iny
456 sty __sector
457
458 rts
459
460 org page2+255
461 db 0 ; thus we have a full 512-bytes loader
462
463
464
465 MFM_DISK 02 00 00 00 2A 00 00 00 [offset $00]
466 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
467 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E [offset $100 / 256]
468
469 fwrite(new_signature,8,1,fd);
470 fwrite(&sides,1,4,fd); fwrite(&tracks,1,4,fd); fwrite(&geometry,1,4,fd);
471 fwrite(header+20,256-20,1,fd);
472
473
474 int offset=header_dsk; // on ajoute le header
475 offset+=track*6400; // On avance à la bonne piste
476 offset+=(taille_secteur+nb_oct_after_sector+nb_oct_before_sector)*(sector-1);
477
478 #define nb_oct_before_sector 59 // Cas de 17 secteurs/pistes !
479 #define nb_oct_after_sector 43 //#define nb_oct_after_sector 31
480
481
482 Une piste SEDORIC, formatée à 17 secteurs, compte 96 octets de début de piste + 17 secteurs de 358 octets + 98 octets de fin de piste = 6280 octets.
483 -> 256+59+43=358
484
485
486 Une piste SEDORIC, formatée à 19 secteurs, compte 0 octet de début de piste + 19 secteurs de 328 octets + 48 octets de fin de piste = 6280 octets.
487 On comprend mieux le manque de fiabilité du formatage en 19 secteurs/piste dû à la faible largeur des zones de sécurité (12 [#4E] entre chaque secteur et 48 octets entre le dernier et le premier).
488
489 Lors de l'élaboration du tampon de formatage SEDORIC, les octets #C2 sont remplacés par des octets
490 #F6, les octets #A1 sont remplacés par des octets #F5 et chaque paire de 2 octets [CRC CRC] et
491 remplacée par un octet #F7. Comme on le voit, nombre de variantes sont utilisées, sauf la zone 22 [#4E],
492 12 [#00], 3 [#A1] qui est strictement obligatoire.
493
494
495
496 for(s=0;s<sides;s++)
497 {
498 for(t=0;t<tracks;t++)
499 {
500 offset=gap1;
501 for(i=0;i<sectors;i++)
502 {
503 trackbuf[offset+4]=t;
504 trackbuf[offset+5]=s;
505 trackbuf[offset+6]=i+1;
506 trackbuf[offset+7]=1;
507 compute_crc(trackbuf+offset,4+4);
508 offset+=4+6;
509 offset+=gap2;
510 memcpy(trackbuf+offset+4,bigbuf+((s*tracks+t)*sectors+i)*256,256);
511 compute_crc(trackbuf+offset,4+256);
512 offset+=256+6;
513 offset+=gap3;
514 }
515 fwrite(trackbuf,6400,1,fd);
516 }
517 }
518
519 // From DskTool:
520 15, 16 or 17 sectors: gap1=72; gap2=34; gap3=50;
521 18 sectors: gap1=12; gap2=34; gap3=46;
522
523 Format of a track:
524 6400 bytes in total
525 - gap1: 72/12 bytes at the start of the track (with zeroes)
526 Then for each sector:
527 - ?: 4 bytes (A1 A1 A1 FE)
528 - track number: 1 byte (0-40-80...)
529 - side number: 1 byte (0-1)
530 - sector number: 1 byte (1-18-19)
531 - one: 1 byte (1)
532 - crc: 2 bytes (crc of the 8 previous bytes)
533 - gap2: 34 bytes (22xAE , 12x00)
534 - ?: 4 bytes (A1 A1 A1 FB)
535 - data: 256 bytes
536 - crc: 2 bytes (crc of the 256+4 previous bytes)
537 - gap3: 50/46 bytes
538
539
540
541 Here is the content of DEFAULT.DSK:
542 Size: 537856 bytes
543
544 Header: 256 bytes:
545 - Signature: 8 bytes (MFM_DISK)
546 - Sides: 4 bytes (2)
547 - Tracks: 4 bytes (42/$2A)
548 - Geometry: 4 bytes (1)
549 - Padding: 236 bytes (000000...00000 )
550
551 So, 537856-256=537600 bytes of data for the floppy itself.
552 537600/2 sides =268800 bytes per side
553 268800/42 tracks=6400 bytes per track
554
555 Sectors identified:
556 - 0x16C / 364 -> A1 A1 A1 FE Track:00 Side:00 Sector:01 01 CRC:FA 0C
557 - 0x2D2 / 722 -> A1 A1 A1 FE Track:00 Side:00 Sector:02 01 CRC:AF 5F
558 - 0x438 / 1080 -> A1 A1 A1 FE Track:00 Side:00 Sector:03 01 CRC:9C 6E
559
560 First sector at offset 364, minus 256 bytes header -> 98 bytes start of track.
561
562 The boot sector is copied at 0x319
563 - 0x2C6 -> |00 00 00 00 00 00 00 00 00 00 00 00|A1 A1 A1 FE Track:00 Side:00 Sector:02 01 CRC:AF 5F|4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E|
564 - 0x2F2 -> |00 00 00 00 00 00 00 00 00 00 00 00|A1 A1 A1 FB [Start of boot sector data]
565 - 0x302 -> 00 00 FF 00 D0 9F D0 9F 02 B9 01 00 FF 00 00 B9 E4 B9 00 00 E6 12 00[BOOT EXECUTABLE DATA]
566 ^
567 +- 00 if Master, 01 if Slave
568
569 23 bytes of crap before the actual boot loading address
570 These 23 bytes seem confirmed by Sedoric a nu (page 489), that would mean we have 256-23=233 bytes in the boot code.
571
572 Actual bytes of BOOTSECTOR.O: 78 A9 60 85 00 20 00 00 BA CA 18 BD 00 01 69 22
573
574 SYSTEMDOS
575 BOOTUPCOM
576
577
578 Track header:
579 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E
580 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E
581 4E 4E 4E 4E 4E 4E 4E 4E 00 00 00 00 00 00 00 00
582 00 00 00 00 C2 C2 C2 FC 4E 4E 4E 4E 4E 4E 4E 4E
583 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E
584 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E
585 00 00 00 00 00 00 00 00 00 00 00 00
586
587 Une piste SEDORIC, formatée à 17 secteurs, compte 96 octets de début de piste + 17 secteurs de 358 octets + 98 octets de fin de piste = 6280 octets.
588 -> 256+59+43=358
589
590
591 ou 12 [#00], 3 [#A1] [#FE #pp #ff #ss #01 CRC CRC], 22 [#4E], 12 [#00], 3 [#A1], [#FB], les 256
592 octets, [CRC CRC], 12, 30 ou 40 octets [#4E] (selon le nombre de secteurs/piste). Soit environ 256 + (72
593 à 100) = 328 à 356 octets pour SEDORIC.
594
595 void compute_crc(unsigned char *ptr,int count)
596 {
597 int i;
598 unsigned short crc=0xFFFF,byte;
599 for (i=0;i<count;i++)
600 {
601 byte= *ptr++;
602 crc=(crc<<8)^crctab[(crc>>8)^byte];
603 }
604 *ptr++=crc>>8;
605 *ptr++=crc&0xFF;
606 }
607
608
609
610 Mais ce n'est pas tout! Le code de la ROM du MICRODISC cherche à charger ORIC DOS à partir de la
611 disquette. Or la structure de la disquette "Master" qui contient SEDORIC est bien différente! Si on passe
612 sur certains détails scabreux (ORIC DOS utilise par exemple des enregistrements de taille variable dans les
613 secteurs, enregistrements contenant leur propre adresse de chargement), le copyright est extrait d'un
614 enregistrement factice (situé dans le secteur numéro 2 de la piste zéro) et les fichiers BOOTUP.COM et
615 SYSTEM.COM sont cherché dans un directory factice (situé dans le troisième secteur de la piste zéro).
616 C'est au tour de SEDORIC de tromper ORIC DOS! La façon dons les systèmes comme SEDORIC font
617 croire à L’EPROM du MICRODISC que la disquette est une ORIC DOS est déjà tout un programme...
618 Le genre d’horreurs nées du souci de compatibilité.
619
620 La question suivante est de savoir comment la ROM du MICRODISC est capable de charger SEDORIC,
621 dont le système de fichiers a une structure différente et qui n'utilise pas d'enregistrements comme
622 ORICDOS. Ceci est réalisé en bernant la ROM, en lui faisant croire qu'il y a bien une disquette ORICDOS
623 dans le lecteur. Les trois premiers secteurs des disquettes SEDORIC servent à imiter un système de fichier
624 ORICDOS. L'ANNEXE suivante vous montre le contenu de ces 3 secteurs. En regardant de plus près, on
625 voit que dans le troisième secteur de la piste zéro, le fichier BOOTUP.COM est soit disant présent dans
626 le deuxième secteur de la piste zéro. Ceci est utilisé pour charger un enregistrement qui est finallement
627 exécuté et ce petit morceau de code est responsable du chargement de SEDORIC en RAM overlay. Bien
628 sûr, il cela aurait été plus simple si ORICDOS chargeait un secteur de boot et l'exécutait juste après! C'est
629 ainsi que le TELEMON du TELESTRAT opère.
630
631 Les 3 premiers secteurs contiennent n( de version, boot et copyright et sont listés ci-après .
632
633 Dump du premier secteur de disquette Master ou Slave (VERSION)
634 0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF
635 0000- 01 00 00 00 00 00 00 00 20 20 20 20 20 20 20 20
636 0010- 00 00 03 00 00 00 01 00 53 45 44 4F 52 49 43 20
637 0020- 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
638 0030- 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
639 0040- 53 45 44 4F 52 49 43 20 56 33 2E 30 30 36 20 30 SEDORIC V3.006 0
640 0050- 31 2F 30 31 2F 39 36 0D 0A 55 70 67 72 61 64 65 1/01/96..Upgrade
641 0060- 64 20 62 79 20 52 61 79 20 4D 63 4C 61 75 67 68 d by Ray McLaugh
642 0070- 6C 69 6E 20 20 20 20 20 20 20 20 20 0D 0A 61 6E lin ..an
643 0080- 64 20 41 6E 64 72 7B 20 43 68 7B 72 61 6D 79 20 d André Chéramy
644 0090- 20 20 20 20 20 20 20 20 20 20 20 20 0D 0A 0D 0A ....
645 00A0- 53 65 65 20 53 45 44 4F 52 49 43 33 2E 46 49 58 See SEDORIC3.FIX
646 00B0- 20 66 69 6C 65 20 66 6F 72 20 69 6E 66 6F 72 6D file for inform
647 00C0- 61 74 69 6F 6E 20 0D 0A 20 20 20 20 20 20 20 20 ation ..
648 00D0- 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
649 00E0- 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
650 00F0- 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
651
652 Dump du deuxième secteur de disquette Master ou Slave (COPYRIGHT)
653 0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF
654 0000- 00 00 FF 00 D0 9F D0 9F 02 B9 01 00 FF 00 00 B9
655 0010- E4 B9 00 00 E6 12 00 78 A9 7F 8D 0E 03 A9 10 A0 01 si Slave
656 0020- 07 8D 6B 02 8C 6C 02 A9 86 8D 14 03 A9 BA A0 B9
657 0030- 20 1A 00 A9 84 8D 14 03 A2 02 BD FD CC 9D F7 CC
658 0040- CA 10 F7 A2 37 A0 80 A9 00 18 79 00 C9 C8 D0 F9
659 0050- EE 37 B9 CA D0 F3 A2 04 A8 F0 08 AD 01 B9 A8 D0
660 0060- 02 A2 3C 84 00 A9 7B A0 B9 8D FE FF 8C FF FF A9
661 0070- 05 8D 12 03 A9 85 8D 14 03 A9 88 8D 10 03 A0 00
662 0080- 58 AD 18 03 30 FB AD 13 03 99 00 C4 C8 4C 6C B9
663 0090- A9 84 8D 14 03 68 68 68 AD 10 03 29 1C D0 D5 EE
664 00A0- 76 B9 EE 12 03 CA F0 1F AD 12 03 CD 00 B9 D0 C1
665 00B0- A9 58 8D 10 03 A0 03 88 D0 FD AD 10 03 4A B0 FA
666 00C0- A9 01 8D 12 03 D0 AA A9 C0 8D 0E 03 4C 00 C4 0C
667 00D0- 11 53 45 44 4F 52 49 43 20 56 33 2E 30 0A 0D 60 .SEDORIC V3.0..`
668 00E0- 20 31 39 38 35 20 4F 52 49 43 20 49 4E 54 45 52 1985 ORIC INTER
669 00F0- 4E 41 54 49 4F 4E 41 4C 0D 0A 00 00 00 00 00 00 NATIONAL........
670
671 Cet exemple provient d'une disquette Master vierge, formatée en 42 pistes de 17 secteurs, simple face. Le
672 seul octet qui diffère de son homologue de la version 1.006 est indiqué en gras. En 00D1, le message de
673 COPYRIGHT devient:
674 "SEDORIC V3.0
675 © 1985 ORIC INTERNATIONAL"
676 Remarquez le contenu de l'octet n°#16 qui vaut ici #00 et indique qui s'agit d'une disquette Master.
677 Désassemblage du deuxième secteur de disquette master
678 Cette routine est probablement mise en jeu lors du BOOT. Elle semble charger SEDORIC en RAM overlay.
679 Il faudrait connaître la signification des registres d'I/O du contrôleur de disquette pour pouvoir en
680 comprendre les détails.
681
682 +23 !
683 0017- 78 SEI interdit les interruptions
684 0018- A9 7F LDA #7F A = 0111 1111
685 001A- 8D 0E 03 STA 030E b7 de 030E à 0 pour interdire les interruptions
686 001D- A9 10 LDA #10
687 001F- A0 07 LDY #07
688 0021- 8D 6B 02 STA 026B PAPER = #10 (noir)
689 0024- 8C 6C 02 STY 026C INK = 07 (blanche)
690 0027- A9 86 LDA #86
691 0029- 8D 14 03 STA 0314 #86 I/O contrôleur de disquette
692 002C- A9 BA LDA #BA
693 002E- A0 B9 LDY #B9 AY = #BAB9
694 0030- 20 1A 00 JSR 001A afficher la chaîne pointée par AY
695 0033- A9 84 LDA #84
696 0035- 8D 14 03 STA 0314 #84 I/O contrôleur de disquette
697 0038- A2 02 LDX #02 pour copie de 3 octets de CCFD/CCFF en CCF7/CCF9
698
699
700 00 00 "lien" (coordonnées du descripteur suivant). Ici le #0000 pointe sur le secteur n°0 de la piste n°0, ce qui indique qu'il n'y a pas d'autre descripteur, car un numéro de secteur ne peut jamais être nul.
701 FF contient #FF (seulement si premier secteur descripteur) (Le pointeur X est positionné sur ce #FF, et permet de lire la suite
702 00 (C101+X) type de fichier (voir manuel page 100). Ici #40, soit 0100 0000, indique qu'il s'agit d'un fichier de type "Bloc de données" (b6 à 1)
703 D0 9F (C102+X et C103+X) adresse (normale) de début (ou nombre de fiches pour un fichier à accès direct). Ici #C400 est le début de la BANQUE n°7 en RAM overlay.
704 D0 9F (C104+X et C105+X) adresse (normale) de fin (ou longueur d'une fiche pour un fichier à accès direct). Ici #C7FF est la fin de la BANQUE n°7 en RAM overlay.
705 02 B9 (C106+X et C107+X) adresse d'exécution si AUTO, #0000 si non AUTO.
706 01 00 (C108+X et C109+X) nombre de secteurs à charger. La BANQUE n°7 comporte 4 secteurs, d'où le #0004 qui figure ici
707 FF 00 (C100+Y et C101+Y) liste coordonnées piste/secteur des secteurs à charger. Ici le premier secteur de la BANQUE n°7 se trouve au secteur n°11 (#0B) de la piste n°5 (#05), le dernier au secteur n°14 (#0E) de cette même piste. Dans un premier descripteur il y a de la place pour 122 paires de 2 octets. Si le nombre de secteurs à charger dépasse 122, lorsque Y atteint #00 (fin BUF1), il faut charger le descripteur suivant dont la structure est simplifiée:
708 00 B9 "lien" (coordonnées du descripteur suivant)
709 E4 B9
710 00 00 E6 12
711 00
712
713
714 Les 3 premiers secteurs contiennent n( de version, boot et copyright et sont listés ci-après .
715
716 Dump du premier secteur de disquette Master ou Slave (VERSION)
717 0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF
718 0000- 01 00 00 00 00 00 00 00 20 20 20 20 20 20 20 20
719 0010- 00 00 03 00 00 00 01 00 53 45 44 4F 52 49 43 20
720 0020- 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
721 0030- 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
722 0040- 53 45 44 4F 52 49 43 20 56 33 2E 30 30 36 20 30 SEDORIC V3.006 0
723 0050- 31 2F 30 31 2F 39 36 0D 0A 55 70 67 72 61 64 65 1/01/96..Upgrade
724 0060- 64 20 62 79 20 52 61 79 20 4D 63 4C 61 75 67 68 d by Ray McLaugh
725 0070- 6C 69 6E 20 20 20 20 20 20 20 20 20 0D 0A 61 6E lin ..an
726 0080- 64 20 41 6E 64 72 7B 20 43 68 7B 72 61 6D 79 20 d André Chéramy
727 0090- 20 20 20 20 20 20 20 20 20 20 20 20 0D 0A 0D 0A ....
728 00A0- 53 65 65 20 53 45 44 4F 52 49 43 33 2E 46 49 58 See SEDORIC3.FIX
729 00B0- 20 66 69 6C 65 20 66 6F 72 20 69 6E 66 6F 72 6D file for inform
730 00C0- 61 74 69 6F 6E 20 0D 0A 20 20 20 20 20 20 20 20 ation ..
731 00D0- 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
732 00E0- 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
733 00F0- 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 2
734
735 */
736
737 nov. 23 19:05:26 <_Dbug_> I have a question: In all the C64 demos I've seen recently was written "Loader: Krill", is it the de-factor standard in loading system and every group uses it?
738 nov. 23 19:06:06 <_Fungus_> most people are using krill's loader now yes
739 nov. 23 19:06:19 <iAN_CooG> then some use cadaver's, some soundemon's
740 nov. 23 19:06:40 <Krillye> _Dbug_: not all use them, but it's something like the market leader atm :)
741 nov. 23 19:06:50 <AuMTRoN> krill is the holy grail of loaders... krill can even load demos from loafs of bread etc...
742 nov. 23 19:07:10 <algorithm> krills loader is the best at the moment
743 nov. 23 19:07:18 <_Fungus_> I've seen a few demos use mine
744 nov. 23 19:07:35 <algorithm> lft's one is nice as well with some decent features, but uses more resources
745 nov. 23 19:07:49 <Krillye> algorithm: hmm, what resources?
746 nov. 23 19:07:54 <AuMTRoN> the only one i ever used was plushlload... which i assume was krill too
747 nov. 23 19:08:03 <Krillye> lft's loader still has some speed features i need to copy... some day
748 nov. 23 19:08:04 <algorithm> the gcr decode uses more stack area
749 nov. 23 19:08:07 <_Dbug_> Just for my own knowledge, what does the loader do, does it handle things like decompression, hardware compatibility, stuff like that? Or is it because it's very compact and fast?
750 nov. 23 19:08:12 <XmikePOA> http://linusakesson.net/programming/gcr-decoding/index.php
751 nov. 23 19:08:17 <Krillye> AuMTRoN: yes, very old codebase
752 nov. 23 19:08:17 <AuMTRoN> (and indeed, it was quite ok to use)
753 nov. 23 19:08:28 <Krillye> AuMTRoN: not really related to current one
754 nov. 23 19:08:34 <AuMTRoN> nono, i understand
755 nov. 23 19:08:45 <algorithm> dbug. decompression via exomizer etc while loading
756 nov. 23 19:08:54 <algorithm> and rather compact.
757 nov. 23 19:09:07 <Krillye> _Dbug_: the basic idea is to be able to load while irqs and sprites etc. may keep running, other than the rom routines
758 nov. 23 19:09:36 <Krillye> _Dbug_: but yes, it can also decompress on the fly and also abstracts hw, as in works on a few different drives
759 nov. 23 19:09:56 <Krillye> (even vice without true drive emu, but nobody seems to enable the feature)
760 nov. 23 19:10:41 <Krillye> _Dbug_: compactness (and speed) is configurable, depends on the settings, which depend on your needs
761 nov. 23 19:10:53 <_Dbug_> Basically I got the annoying task of maintenaing our Oric loader (the guy who wrote it has left) and I'm trying to figure out how to make it evolve. Like how to define files structures on disk, if I need some 'api' to load files, how to insert irqs or if I should provide optimzed default stuff for music and such
762 nov. 23 19:11:23 <_Dbug_> I guess all the annoying sync stuff is on the drive side on the c64?
763 nov. 23 19:11:35 <Krillye> _Dbug_: hmm sounds a lot more like a framework (similar to lft's "loader") than a loader :)
764 nov. 23 19:11:36 <_Fungus_> both sides
765 nov. 23 19:12:03 <_Fungus_> it's called handshaking
766 nov. 23 19:12:31 <Krillye> _Dbug_: the loader takes care of that, the protocol it implements can be interrupted arbitrarily by sprites, dma, interrupts, you name it
767 nov. 23 19:13:15 <_Dbug_> Krillye: Right now I have been given a 'FloppyMaker.exe' that takes a text files as an input, pointing to a list of binary resources, and it outputs some assembler array data with track/sector/lenght information which is included by a beautifull (and buggy) 'loader.s'
768 nov. 23 19:13:38 <Krillye> _Dbug_: yes, i see
769 nov. 23 19:14:24 <_Dbug_> My main problem is that the 'load sector' is basically blocking, all IRQ is disabled, so I would like to do somethinh like... change stuff on screen while it loads! or ... play sounds! (right now yo uget a black screen and no soumd)
770 nov. 23 19:14:24 <algorithm> for users who do not want to build sources, i guess you can have some predefined binaries with some code to relocate
771 nov. 23 19:14:30 <Krillye> _Dbug_: sounds a lot like lft's thingy, minus the bugs :D
772 nov. 23 19:15:01 <Krillye> _Dbug_: however, that's a different approach compared to the classic one, which my loader implements
773 nov. 23 19:15:12 <Krillye> but i have no idea what's classic and what not, on oric
774 nov. 23 19:15:43 <_Dbug_> classic on the oric is 'use the slow system loader and lose 16kb of ram in the process'
775 nov. 23 19:15:57 <Krillye> _Dbug_: there is no way to have the block load be pre-emptible?
776 nov. 23 19:16:06 <_Dbug_> My group is the only one who actually wrote a custom loader
777 nov. 23 19:16:11 <Krillye> like on atari? (lol)
778 nov. 23 19:16:56 <_Dbug_> The problem is that in my case when I get a sector read, I start to receive bytes and I have like 36 cycles between each byte, there's only a one byte buffer so if I'm too fast or too slow I miss data
779 nov. 23 19:17:11 <_Dbug_> That makes it hard to play generic code :)
780 nov. 23 19:17:41 <_Dbug_> Of course I can poll a register to read if there's data available... but then I lose cpu time for just testing stuff...
781 nov. 23 19:18:45 <Krillye> _Dbug_: work out the variance or that stuff, then write a code-knitter (tm) to fill in the wait times between the polls/fetches :D
782 nov. 23 19:19:05 <_Dbug_> Hmm... that's not actually stupid...
783 nov. 23 19:19:16 <_Dbug_> Not memory efficient... but that could work
784 nov. 23 19:19:31 <_Dbug_> demo code (read byte) demo code (read byte) some more demo code (read byte)
785 nov. 23 19:19:31 <Krillye> actually i've been thinking about something like that for streaming in samples
786 nov. 23 19:19:57 <_Fungus_> does oric only have like 16k ram or something?
787 nov. 23 19:20:05 <Krillye> because that's just 126 cycles between the samples, but putting diskfetch stuff in between reduces irq-context-switch overhead
788 nov. 23 19:20:29 <_Dbug_> _Fungus_, it has 64k of ram, the top 16k are overlaid by the ROM but you can page it out
789 nov. 23 19:20:38 <_Fungus_> are the drives smart, or are they dumb peripherals controlled by the host
790 nov. 23 19:20:52 <_Dbug_> dump drive, it's basically a WDC controller directly on the bus
791 nov. 23 19:21:12 <_Fungus_> should make it easier to code
792 nov. 23 19:21:19 <_Dbug_> yeah but there's zero buffering
793 nov. 23 19:21:33 <locutus> plain WDC on bus, sounds simple enough
794 nov. 23 19:21:38 <Krillye> _Dbug_: 64k is plenty, you can generate that interleaved code at run-time
795 nov. 23 19:21:39 <_Dbug_> I can do whatever I want between the read sector calls, but when the call is done I have to get the data when it arrives
796 nov. 23 19:22:11 <_Dbug_> there's a status byte, there's an irq line as well
797 nov. 23 19:22:30 <_Dbug_> funny thing is that in irq mode it takes so long to get the irq called anre returned that basically all you can do is fetch and store
798 nov. 23 19:22:49 <Krillye> yeah, so poll + interleaved code
799 nov. 23 19:22:49 <_Dbug_> so the polling mode is better, but that kills a bit of performance to test the status byte
800 nov. 23 19:23:15 <_Dbug_> Could be something to try. Thanks for the idea :)
801 nov. 23 19:23:22 <_Fungus_> then yeah you'll just have to code parts around the loader then
802 nov. 23 19:23:36 <Krillye> well, work out the variance. if you get it down to a fraction of a cycle, you only need to poll once every few bytes
803 nov. 23 19:23:43 <Krillye> to add a cycle or not
804 nov. 23 19:23:47 <_Dbug_> I guess I could just write a simple MACRO that performs 'read next byte and store'
805 nov. 23 19:24:10 <_Dbug_> Yeah like synchronize, fetch 10 bytes, synchronize, etc...
806 nov. 23 19:24:34 <Krillye> more like sync demo demo demo fetch demo demo demo fetch demo demo demo sync ...
807 nov. 23 19:24:35 <Krillye> :)
808 nov. 23 19:25:00 <_Dbug_> (I meant 'demo/fetch/demo/fetch' 10 times then synchronize and repeat)
809 nov. 23 19:25:12 <Krillye> yeah
810 nov. 23 19:25:13 <Krillye> :)
811 nov. 23 19:25:15 <_Dbug_> But yeah, could work
812 nov. 23 19:25:34 <Krillye> the tricky part is to work around the register restrictions
813 nov. 23 19:25:37 <_Dbug_> I will test first on something simple like rasters, could be nice to be able to move that while loading :)
814 nov. 23 19:25:45 <Krillye> :)
815 nov. 23 19:26:18 <_Dbug_> Yeah I guess I can make the MACRO have the 'register to use' as a parameter
816 nov. 23 19:26:54 <_Dbug_> perform an LDA/LDX/LDY on the port based on that, and write at fixed address in a buffer
817 nov. 23 19:27:16 <_Dbug_> (and have the macro increment the next absolute address after each call)
818 nov. 23 19:27:17 <Krillye> use pha
819 nov. 23 19:27:30 <Krillye> 3 cycle with auto-increment on pointer
820 nov. 23 19:27:33 <Krillye> +s
821 nov. 23 19:27:37 <_Dbug_> I will run out of stack size
822 nov. 23 19:27:48 <_Dbug_> I have 256 bytes to load
823 nov. 23 19:27:53 <Krillye> not while the block is f... ok
824 nov. 23 19:28:08 <groepaz> 256 is fine, no? :)
825 nov. 23 19:28:11 <jbevren> need moar stack
826 nov. 23 19:28:12 <Krillye> then sta abs : inc *-2
827 nov. 23 19:28:35 <_Dbug_> I guess technically I do not need the stack while loading...
828 nov. 23 19:28:36 <Krillye> or hmm.... tricky
829 nov. 23 19:28:37 <algorithm> stack galore
830 nov. 23 19:28:54 <jbevren> lda disk pha lda disk
831 nov. 23 19:28:55 <jbevren> hehe
832 nov. 23 19:29:01 <Krillye> copying the stack takes a lot of performance.. but you can knit that into the code as well
833 nov. 23 19:29:03 <_Dbug_> Disable irq, save the stack pointer, reset S to 255, the lds pha lda pha lda pha
834 nov. 23 19:29:08 <algorithm> unless you are jsr'ing via interleaved code, then should have ample stack
835 nov. 23 19:29:28 <_Dbug_> Guess that can work... if it crashes will be awesome to debug :D
836 nov. 23 19:29:33 <groepaz> jbevren: LDA and STA
837 nov. 23 19:29:43 <jbevren> gpz- ah, I see many lda's in your code
838 nov. 23 19:29:43 <_Dbug_> That also basically mean I have to use A for fetching
839 nov. 23 19:29:50 <Krillye> _Dbug_: rest assured it WILL crash until you got it all right :)
840 nov. 23 19:29:58 <_Dbug_> Yeah I can expect that for sure
841 nov. 23 19:30:01 <Krillye> crash in very creative ways
842 nov. 23 19:30:24 <Krillye> but... disable irqs but still have an irq handler, to catch brk's
843 nov. 23 19:30:32 <Krillye> easier to debug :)
844 nov. 23 19:30:37 <_Dbug_> So basically, a read sector becomes 256 calls to LDA port, PHA, with some demo code in between, followed by a PLA loop that stores in the final buffer
845 nov. 23 19:31:26 <Krillye> _Dbug_: yes... unless you must poll data for a whole revolution, then no time between sectors
846 nov. 23 19:31:27 <_Dbug_> I'm sure that would do an efficient protection as well. Any sucker trying to use the stack gets atomized :)
847 nov. 23 19:31:51 <_Dbug_> I have control on the interleave
848 nov. 23 19:31:58 <Krillye> very good
849 nov. 23 19:32:10 <_Dbug_> (At least I'm supposed to, never actually tried :D)
850 nov. 23 19:32:18 <Krillye> you could then even skip bytes inside sectors
851 nov. 23 19:32:26 <Krillye> and not use the stack after all
852 nov. 23 19:32:29 <Krillye> or just parts of it
853 nov. 23 19:33:04 <_Dbug_> Will experiment :)
854 nov. 23 19:33:10 <_Dbug_> Thanks for sharing ideas!
855 nov. 23 19:33:24 <Krillye> so... you have a couple of knobs to turn, but the bottom line is interwoven loader and demo coe
856 nov. 23 19:33:25 <Krillye> code
857 nov. 23 19:33:25 <Krillye> :)
858 nov. 23 19:33:44 <_Dbug_> Yeah. Well if I can achieve that, that will be a first on the oric.
859 nov. 23 19:33:50 <Krillye> :D
860 nov. 23 19:33:52 <AuMTRoN> knobs to turn == balls on top
861 nov. 23 19:33:58 <Krillye> GO!
862 nov. 23 19:34:13 <_Dbug_> And that means the end of the bip bip bip bip [no soud except toc toc toc toc] bip bip bip of the current oric demos
863
864
865
866 // BORN.DSK=537856 bytes
867 // 17*358=6086
868 // *2=12172
869 // *44=537856
870
871 // Boot sector at offset 793 (Confirmed)
872 // Loader at offset 0x734 (1844) - Confirmed
873
874 // 793-256-156=381
875 // 381-256=125
876
877 // offset=256+156; // on ajoute le header
878 // offset+=track*6400; // On avance à la bonne piste
879 // offset+=(taille_secteur+nb_oct_after_sector+nb_oct_before_sector)*(sector-1);
880 //
881 // So: Offset = 256+156 + (track*6400) + (taille_secteur+nb_oct_after_sector+nb_oct_before_sector)*(sector-1)
882 // = 256+156 + (track*6400) + (256+43+59)*(sector-1)
883 // = 412 + (track*6400) + (358)*(sector-1)

  ViewVC Help
Powered by ViewVC 1.1.26