csg019@cck.cov.ac.uk (Z*A*P*H*O*D) (11/27/90)
Hi peeps, i seem to recall someone asking for some code to read disks, and some info on MFM coding. Well, we'll start at the begining, the amiga uses 11 sectors per track, 2 sides, and 80 tracks, it stores the information on the disks using a method of encryption called MFM coding. This method helps to detect errors, and allows the track to be split into the 11 sectors. Each sector has a sector header (64 bytes) which is coded slightly differently from the rest of the track. There are actually 22 sectors on one side of a DOS disk, but these are combined to produce one sector. The coding of the sectors requires the first longword of sector 1 to be decoded with the first long word of the next sector (1 sector = 512 ($200) bytes)). To further complecate things, each track has a gap that contains no useable data. To cut a long story short, here is an assemly language program to read DOS disks using MFM coding. It was written in DEVPAC II but should be compatable with other assemblers like Argasm (nice little plug there eh FUZZZ???) Hope this helps the guy from London a bit! To protect you own software you should write a track with just one long sector of a strange length and have a custome routine on the bootblock to load it. I'm not a cracker and i am just just trying to help so no flames! Well i suppose i'm in for a flaming from all thos Americans that thing that games should multitask with 400 drives and 9 gigabytes of RAM, but still here goes..... * CODE WRITTEN BY ZAPHOD OF INTUITION * SECTION disk_map,code_c num_tracks = 10 Number of tracks -1 to read step_wait = 3000 Delay for track movement *Make program an exception for super mode start move.l $80,trap_save move.l #program_start,$80 trap #0 move.l trap_save,$80 rts program_start bsr save_status Set system bsr motor_on bsr seek_zero move.w #num_tracks,d4 read_more bsr read_track bsr decode bsr seek_80 Read tracks dbra d4,read_more bsr motor_off bsr restore_status rte *Track in until 0 is found seek_zero btst #4,$bfe001 beq found_0 bset #1,$bfd100 bclr #0,$bfd100 bset #0,$bfd100 bsr stepper_delay bra seek_zero found_0 rts seek_80 bclr #1,$bfd100 bclr #0,$bfd100 bset #0,$bfd100 bsr stepper_delay rts stepper_delay move.w #step_wait,d1 wait dbra d1,wait wait_command btst.b #5,$bfe001 bne.s wait_command rts read_track *Read block header move.w #$8210,$dff096 move.w #$4000,$dff024 move.w #$4489,$dff07e move.w #$8400,$dff09e move.l #$60000,$dff020 move.w #$8000+16,$dff024 move.w #$8000+16,$dff024 bsr wait_dma Wait for block done bsr clear_ints Clear interupts *Decode header move.l $60002,d0 move.l $60006,d1 andi.l #$55555555,d0 andi.l #$55555555,d1 lsl.l #1,d0 or.l d1,d0 cmp.b #1,d0 Next sector is gap? bne.s read_track No, read next sector lsr.w #8,d0 Yep, then get this sector numer cmp.b #10,d0 bne not_10 move.b #0,d0 bra.s doner not_10 add.b #1,d0 move.b d0,sector_number Store it doner move.w #$8210,$dff096 move.w #$4000,$dff024 move.w #$4489,$dff07e move.w #$8400,$dff09e move.l #$60000,$dff020 move.w #$8000+($220*11),$dff024 move.w #$8000+($220*11),$dff024 bsr wait_dma bsr clear_ints rts motor_delay move.w #$b000,d0 md dbra d0,md rts decode moveq.l #0,d0 move.b sector_number,d0 move.l d0,d1 mulu.w #512,d1 move.l #10,d2 sub.l d0,d2 lea $60000+58,a0 lea $60000+512+58,a2 lea $70000,a1 add.l d1,a1 dl2 move.w #(512/4)-1,d6 dl move.l (a0)+,d0 move.l (a2)+,d1 andi.l #$55555555,d0 andi.l #$55555555,d1 lsl.l #1,d0 or.l d1,d0 move.l d0,(a1)+ dbra d6,dl add.l #$240,a0 add.l #$240,a2 dbra d2,dl2 cmp.b #0,sector_number beq dones clr.l d2 move.b sector_number,d2 sub.w #1,d2 lea $70000,a1 dl3 move.w #(512/4)-1,d6 dl4 move.l (a0)+,d0 move.l (a2)+,d1 andi.l #$55555555,d0 andi.l #$55555555,d1 lsl.l #1,d0 or.l d1,d0 move.l d0,(a1)+ dbra d6,dl4 add.l #$240,a0 add.l #$240,a2 dbra d2,dl3 rts dones move.w #$fff,$dff180 rts save_status move.w $dff01c,saveints Save interupt stat move.w $dff002,savedma Save dma stat. move.w #$7fff,$dff09c Clear interupts rts motor_on move.b #%01111111,$bfd100 move.b #%11110011,$bfd100 bsr motor_delay rts motor_off move.b #$fd,$bfd100 nop nop move.b #%01111111,$bfd100 move.b #%11111111,$bfd100 bsr motor_delay rts restore_status move.w saveints,d0 or.w #$c000,d0 move.w d0,$dff01c move.w savedma,d0 or.w #$8100,d0 move.w d0,$dff096 rts wait_dma btst #1,$dff01f beq.s wait_dma rts clear_ints move.w #$4000,$dff024 move.w #$7fff,$dff09c rts saveints dc.w 0 savedma dc.w 0 trap_save dc.l 0 sector_number dc.b 0 -- *********/// O O **A member of S.H.I.T. (Super High Intelegence Team)**///*** * /// u Fight, defeat and kill organized laming. /// * * \\\ /// --- Zaphod of Intuition csg019@uk.ac.cov.cck ok? \\\ /// * ****\\X//**********************************************************\\X//******
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (11/28/90)
In <1990Nov27.113820.28055@cck.cov.ac.uk>, csg019@cck.cov.ac.uk (Z*A*P*H*O*D) writes: > >Well i suppose i'm in for a flaming from all thos Americans that thing that >games should multitask with 400 drives and 9 gigabytes of RAM, but still >here goes..... Well, I'm not an American, but I won't bother flaming you. It was easier to just throw it away. -larry -- The only things to survive a nuclear war will be cockroaches and IBM PCs. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
riley@batcomputer.tn.cornell.edu (Daniel S. Riley) (11/29/90)
[ warning...flames ahead ] In article <1990Nov27.113820.28055@cck.cov.ac.uk> csg019@cck.cov.ac.uk (Z*A*P*H*O*D) writes: [...] >step_wait = 3000 Delay for track movement and >stepper_delay > move.w #step_wait,d1 >wait > dbra d1,wait and >motor_delay > move.w #$b000,d0 >md > dbra d0,md > rts A game programmer fer sure... Let me guess: for high performance games on the Amiga, your players demand that floppy disk access be finely tuned for the 68000--if it didn't have timing loops, then it just wouldn't be worth playing. *sigh* This is the sort of mindless coding that leads to programs that break on accelerated Amigas for *no* defensible reason whatsoever. Timing this with one the CIA timers would take about 6 more lines of assembly. Commodore will even tell you how to do it--read Bryce's article "Amiga Low-Level Disk Access" in AmigaMail volume 1, page VIII-9. Using timing loops in floppy access code is just pure laziness on the part of programmers who can't seem to understand that the Amiga is not a C-64. Don't copy this code--get the AmigaMail article and learn to do it right. A rare flame from the keyboard of -Dan Riley (riley@theory.tn.cornell.edu, cornell!batcomputer!riley) -Wilson Lab, Cornell University
drxmann@ccwf.cc.utexas.edu (Dustin Christmann) (11/29/90)
In article <1990Nov27.113820.28055@cck.cov.ac.uk> csg019@cck.cov.ac.uk (Z*A*P*H*O*D) writes: > >Well i suppose i'm in for a flaming from all thos Americans that thing that >games should multitask with 400 drives and 9 gigabytes of RAM, but still >here goes..... > [ATTENTION...INCOMING FLAME AND OBLIGATORY BUCKET OF VOMIT] Well, hoser, why did you bother buying a multitasking computer if you don't give a flip about multitasking? I know I do. While I'm on my soapbox...how about you Europeans' for once writing a multidisk game, demo, whatever that will take notice that you have more than one floppy drive, or doesn't yak big time if you happen to be one of the growing number of people with a hard drive. Or maybe a program that can cope with more than 512K chip RAM, or more than 512K of RAM, period. In other words, a program that doesn't crash on anything more than a stock 500 with a monitor. It's not too much to ask for. Programmers in the US have seen the writing on the wall (for the most part, except, notably, Electronic Farts) and have re- sponded with programs truly designed for the Amiga's potential as more than a pretty darn good game machine. Coming to you with 3 MB RAM, Huge Agnus, 2 floppy drives, 40 MB hard disk, and an attitude... Lunk, lunk, lunk, *RULPS* Dustin R. Christmann Internet: drxmann@ccwf.cc.utexas.edu Bitnet: DRXMANN@UTXVM Sam: What's happenin', Norm? Norm: It's a dog-eat-dog world out there, and I'm wearin' Milk Bone underwear... -Taken from _Cheers_
dvljhg@cs.umu.se (J|rgen Holmberg) (11/29/90)
In article <40337@ut-emx.uucp> drxmann@ccwf.cc.utexas.edu (Dustin Christmann) writes: >In article <1990Nov27.113820.28055@cck.cov.ac.uk> csg019@cck.cov.ac.uk (Z*A*P*H*O*D) writes: >> >>Well i suppose i'm in for a flaming from all thos Americans that thing that >>games should multitask with 400 drives and 9 gigabytes of RAM, but still >>here goes..... >> >[ATTENTION...INCOMING FLAME AND OBLIGATORY BUCKET OF VOMIT] > >Well, hoser, why did you bother buying a multitasking computer if you don't >give a flip about multitasking? I know I do. > >While I'm on my soapbox...how about you Europeans' for once writing a multidisk >game, demo, whatever that will take notice that you have more than one floppy >drive, or doesn't yak big time if you happen to be one of the growing number of >people with a hard drive. Or maybe a program that can cope with more than 512K >chip RAM, or more than 512K of RAM, period. In other words, a program that >doesn't crash on anything more than a stock 500 with a monitor. > >It's not too much to ask for. Programmers in the US have seen the writing on >the wall (for the most part, except, notably, Electronic Farts) and have re- >sponded with programs truly designed for the Amiga's potential as more than a >pretty darn good game machine. > >Coming to you with 3 MB RAM, Huge Agnus, 2 floppy drives, 40 MB hard disk, and >an attitude... > >Lunk, lunk, lunk, *RULPS* >Dustin R. Christmann > With the main european software producers interested only in making a fast buck through advertising and *cheap* programming that won't happen. There are plenty of good programmers in europe but if you are hired by a games-company like US-GOLD or similar they are not interested in good code. They are interested in fast, flashy coding done as cheap as possible. If european coders will ever produce good it must pay at least remotely as well as making poor games and selling them with big ads. There are MANY coders around that have written good software that simply can't find a company willing to sell a well-written program that doesn't fit their immediate criteria. As long as the users in europe are more interested in buying thirteen games with the same code ( ported from the ST ) and advertised using some film tie-in the bulk of all new software will be *CRAP*. There are good software coming too, check out microproses simulacra (sp?) !!! Jorgen -- ******************************************************************************* email dvljhg@cs.umu.se - other ways to communicate are a waste of time. Everything I say is always true, just apply it to the right reality. "Credo, quia absurdum est."
brett@smosjc.UUCP (Brett Coon) (12/01/90)
>Well, hoser, why did you bother buying a multitasking computer if you don't >give a flip about multitasking? I know I do. [Other similar flames deleted] Geez, give this guy a break! If the original post had requested programmers all over the world to unite against the evils of multitasking, maybe these flames would have been deserved. As is, the original post was merely demonstrating low-level disk routines, written in an admittedly (by the author) not nice way. It's certainly true that software timing loops are bad ideas and that there's no excuse to let code like that posted ever reach a marketed product, but these flames are ignoring the useful information presented. Now that the poster has been thoroughly flamed, I think it's doubtful he'll contribute to further discussions. Besides, the only truly effective way to make programmers stop writing "dirty" code is for us to stop buying it. Flames get us nowhere. Now if someone had taken the time to generate a good version of the posted code, with the timing loops replaced, a real purpose might have been served. -- |Brett Coon | uunet!smosjc!brett | |S-MOS Systems, Inc. | "You like 'em, anchovies?" | |San Jose, CA | -Runaway Train |
jlehmann@wpi.WPI.EDU (Jonas A. Lehmann) (12/01/90)
I agree totally with what was just posted. The fact that everyone was flaming
him for posting code and not at all giving him any credit for sharing some
code with us is really wrong. If all people want to do is flame then go to
alt.flames and do it. I myself did not know 100% how to do this MFM stuff
but thanx to his code I now think I understand it and would really appreciate
to see more code from him even if it may not follow Commodore's rules for
programming the Amiga.
Thanx. Jonas Lehmann - jlehmann@wpi.wpi.edu
PS: Many thanx also to the person who actually provided us with a correct
way to do it.csg019@cck.cov.ac.uk (-~=Zaphod=~-) (12/05/90)
In article <40337@ut-emx.uucp> drxmann@ccwf.cc.utexas.edu (Dustin Christmann) writes: >In article <1990Nov27.113820.28055@cck.cov.ac.uk> csg019@cck.cov.ac.uk (Z*A*P*H*O*D) writes: >> >>Well i suppose i'm in for a flaming from all thos Americans that thing that >>games should multitask with 400 drives and 9 gigabytes of RAM, but still >>here goes..... >> >[ATTENTION...INCOMING FLAME AND OBLIGATORY BUCKET OF VOMIT] > >Well, hoser, why did you bother buying a multitasking computer if you don't >give a flip about multitasking? I know I do. I did n't buy an amiga for its multi tasking capailities. I bought one because i want to push it as far i can. This means speed. When i say speed, i dont mean sharing processor time with other tasks like checking disks while i'm animating 1000 bobs. But thats me. you write/buy programs for what you want, i'll buy/write then for what i want. I'm not preaching what you or anyone else should do, thats one one of the best things about the amiga, its versatile. > >While I'm on my soapbox...how about you Europeans' for once writing a multidisk >game, demo, whatever that will take notice that you have more than one floppy >drive, or doesn't yak big time if you happen to be one of the growing number of >people with a hard drive. Or maybe a program that can cope with more than 512K >chip RAM, or more than 512K of RAM, period. In other words, a program that >doesn't crash on anything more than a stock 500 with a monitor. I see, you mean like paradroid 90 or speedball? >It's not too much to ask for. Programmers in the US have seen the writing on >the wall (for the most part, except, notably, Electronic Farts) and have re- >sponded with programs truly designed for the Amiga's potential as more than a >pretty darn good game machine. > >Coming to you with 3 MB RAM, Huge Agnus, 2 floppy drives, 40 MB hard disk, and >an attitude... > Most of the US games i see don't even bother to redefine the charset. (Bad karma!), or write a fast loader or anything else a it technical. It might even involve looking at the hardware manual, god forbid!!! -- *********/// O O **A member of S.H.I.T. (Super High Intelegence Team)**///*** * /// u Fight, defeat and kill organized laming. /// * * \\\ /// --- Zaphod of Intuition csg019@uk.ac.cov.cck ok? \\\ /// * ****\\X//**********************************************************\\X//******
DXB132@psuvm.psu.edu (12/06/90)
In article <1990Dec5.114110.26904@cck.cov.ac.uk>, csg019@cck.cov.ac.uk (-~=Zaphod=~-) says: >karma!), or write a fast loader or anything else a it technical. By the way, I've yet to see a "fast loader" that's even slightly noticeably faster than trackdisk. (In fact, some of them that wait for the index are SLOWER!). I wonder why some smart programmer doesn't write a really really fast loader? I'll tell you why: it's not possible! The loading time is dominated by the rotation speed of the disk (200ms), so the decoding and other routines that make a loader unique are almost totally irrelevent to the loading time! People still make custom loaders though, because the OS is usually eliminated (another story). Another retorical question: Why can't the people why know how to program the Amiga properly (taking advantage of all available hardware, for example) get together with the people who know how to bang on the hardware to get great arcade games?! Will the two ends ever meet? All you people writing text editors and terminal programs: why not write a game instead just to please me?? :-) (This is not a flame - add smileys until it makes sense). -- Dan Babcock
jesup@cbmvax.commodore.com (Randell Jesup) (12/19/90)
In article <90339.161058DXB132@psuvm.psu.edu> DXB132@psuvm.psu.edu writes: >In article <1990Dec5.114110.26904@cck.cov.ac.uk>, csg019@cck.cov.ac.uk >(-~=Zaphod=~-) says: > >>karma!), or write a fast loader or anything else a it technical. > >By the way, I've yet to see a "fast loader" that's even slightly noticeably >faster than trackdisk. (In fact, some of them that wait for the index are >SLOWER!). I wonder why some smart programmer doesn't write a really really >fast loader? I'll tell you why: it's not possible! The loading time is >dominated by the rotation speed of the disk (200ms), so the decoding and >other routines that make a loader unique are almost totally irrelevent to >the loading time! > >People still make custom loaders though, because the OS is usually eliminated >(another story). Quite true. And if you use trackdisk, you pick up all the improvements we made to it for 2.0. It comes close to the fastest possible now, and even can better 20K/s with FFS floppies. It has all sorts of optimizations to make it faster if you have fastmem, recover from errors better, etc. Also, with trackdisk you're safe from people writing loaders (as has happened a number of times in britain and the rest of europe) which don't work when commodore changes drive manufacturers, or has a genlock installed, or has a system that for other reasons runs a bit slow or fast (we allow +- 5%). Then there are all those loaders that break with '020's or higher, which are becoming quite common in the USA, may even show up in low end machines before long, since the price of an '020 is getting down there. [Flame on!] Currently I'm annoyed because Ultima V (ported by a British firm for Origins) a) doesn't work on anything except 68000's, b) doesn't work with 2.0, even though they take over the machine, because they didn't bother to set up the CIA A modes they wanted, and assumed the values there (2.0 timer uses the CIA's differently). Their disk routines are full of dbra timing loops. We've been telling people how to avoid these problems for years, with source code (see Bryce's and my articles in AmigaMail). From what I hear from European developers on our private UUCP net for European Developer support is that most of the programmers in France (and most other countries) never buy more than the hardware manual, if that. Their main source of docs are the Abacus (Data Becker) books, which include thing direct ROM jumps that break on rom changes, mucking with the internals of other tasks, innumerable hard-coded offsets (because some poor assemblers couldn't deal with include files or such), etc, etc. You CAN write games that either take over cleanly and work on all amigas, or better yet take over cleanly, and exit back cleanly, or even better multitask (at least when paused), all while having smooth animation, sound, etc. Sure it takes work, but it produces a better product, one that won't piss off potential buyers, and will survive OS/machine changes. Because of the MASSIVE piracy problems in Europe, most manufacturers hope to make most of their sales in the first month or two, and after that could care less if it continues to work when the user upgrades their system. If the piracy problems in Europe were more under control, publishers would have more incentive to demand good programming from their developers. The Amiga is not a C64 with more colors, guys! [Flame off for the moment] -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup The compiler runs Like a swift-flowing river I wait in silence. (From "The Zen of Programming") ;-)