mic_

Put me up for a cased Lynx II version.

This is what I use: ; 8-bit channel, 15 kHz clock, octave 1-7 .db $EF,$E2,$D5,$C9,$BE,$B3,$A9,$9F,$96,$8E,$86,$7E .db $77,$70,$6A,$64,$5E,$59,$54,$4F,$4B,$46,$42,$3F .db $3B,$38,$34,$31,$2F,$2C,$29,$27,$25,$23,$21,$1F .db $1D,$1B,$1A,$18,$17,$15,$14,$13,$12,$11,$10,$0F .db $0E,$0D,$0C,$0C,$0B,$0A,$0A,$09,$08,$08,$07,$07 .db $07,$06,$06,$05,$05,$05,$04,$04,$04,$03,$03,$03 .db $03,$03,$02,$02,$02,$02,$02,$02,$01,$01,$01,$01 ; 8-bit channel, 64 kHz clock, octave 3-10 .db $F3,$E6,$D9,$CC,$C1,$B6,$AC,$A2,$99,$90,$88,$80 .db $79,$72,$6C,$66,$60,$5B,$55,$51,$4C,$48,$44,$40 .db $3C,$39,$35,$32,$2F,$2D,$2A,$28,$25,$23,$21,$1F .db $1E,$1C,$1A,$19,$17,$16,$15,$13,$12,$11,$10,$0F .db $0E,$0D,$0D,$0C,$0B,$0A,$0A,$09,$09,$08,$08,$07 .db $07,$06,$06,$05,$05,$05,$04,$04,$04,$04,$03,$03 .db $03,$03,$02,$02,$02,$02,$02,$02,$01,$01,$01,$01 .db $01,$01,$01,$01,$01,$00,$00,$00,$00,$00,$00,$00 ; 16-bit channel, PAL CPU clock, octave 1-12 ; high byte is for AUDFn-1, low byte is for AUDFn .dw $E669,$F463,$585E,$0C59,$0D54,$554F,$E14A,$AD46,$B542,$F63E,$6D3B,$1738 .dw $F134,$F831,$2A2F,$842C,$042A,$A827,$6E25,$5423,$5821,$791F,$B51D,$0A1C .dw $771A,$FA18,$9317,$4016,$0015,$D213,$B512,$A811,$AA10,$BB0F,$D80E,$030E .dw $390D,$7B0C,$C80B,$1E0B,$7E0A,$E709,$5909,$D208,$5308,$DB07,$6A07,$FF06 .dw $9B06,$3C06,$E205,$8D05,$3D05,$F204,$AA04,$6704,$2804,$EC03,$B303,$7E03 .dw $4B03,$1C03,$EF02,$C502,$9D02,$7702,$5302,$3202,$1202,$F401,$D801,$BD01 .dw $A401,$8C01,$7501,$6001,$4C01,$3901,$2801,$1701,$0701,$F800,$EA00,$DC00 .dw $D000,$C400,$B900,$AE00,$A400,$9B00,$9200,$8900,$8100,$7A00,$7300,$6C00 .dw $6600,$6000,$5A00,$5500,$5000,$4B00,$4700,$4300,$3F00,$3B00,$3700,$3400 .dw $3100,$2E00,$2B00,$2900,$2600,$2400,$2100,$1F00,$1D00,$1B00,$1A00,$1800 .dw $1600,$1500,$1400,$1200,$1100,$1000,$0F00,$0E00,$0D00,$0C00,$0B00,$0A00 .dw $0900,$0800,$0800,$0700,$0700,$0600,$0500,$0500,$0400,$0400,$0300,$0300

Just don't go by the wikipedia POKEY article, as it seems to contain some critical errors. This page has a decent amount of info on the POKEY audio parts. I was able to write an audio playback lib based on that page alone.

There's a new version available now where I've optimized the A8 playback library. It's now about 3.5 kB in size, compared to 9 kB in the previous version. Three and a half kB is still not tiny, but one can always compress it if the code/data size really matters. For example, aplib can compress the playback lib down to about 700 bytes and a depacker for 6502 is about 300 bytes.

MML is a way of expressing music in text form. Remember that PLAY statement from QBASIC? Well, it's kind of like that, but a lot more advanced. For example: ; Declare a volume macro that sweeps from 15->0, repeating each value twice (i.e. two frames) @v0 = {15 : 0} ' 2 ; Declare a repeating major chord arpeggio macro @EN0 = {0 4 3 | -7 4 3} A t125 l4 o5 ; Set up channel A to use 125 BPM tempo, quarter notes, octave 5 A L ; channel A's loop point A @5 ; set AUDC distortion bits to %101, i.e. pure tones A @v0 EN0 ; Apply the effect macros declared above A [cdefgab]3 ; repeat this note sequence 3 times A {c+d+f+}8 r1. ; play a C#, D# and F# in the same time it would take to play an 8th note, then rest for a whole + a half note (mutes the channel) There are a lot more things you can do with it. My kit consists of a compiler that you run on Windows that compiles MML files into data files (assembly format) - plus a bunch of playback libraries for various systems (A8, Master System, Gameboy, ...) that can play the compiled music data. That's not really the reverse of this. The reverse of this would take a SAP file and output an MML file. The operation you're proposing should be far simpler than that.

During the last few days I've added POKEY support to my MML compiler kit (which can be found here). It supports all the POKEY h/w features that I know of: you can modify the AUDC distortion bits; you can change the clock base; you can combine pairs of channels into one channel with wider frequency range; and you can activate the high-pass filters. My frequency table for when the CPU clock is used to drive channels 1 or 3 is based on PAL, so it would sound wrong on an NTSC system. There's a batch file in \demo\at8\ that allows you to turn .MML files into .SAP, assuming that you have WLA-DX installed. The playback library is incredibly bloated atm, because I have duplicated code for all 4 channels. I might change that in the future. ..or I might not

Cool, thanks. I noticed that cc65 has support for outputting straight to .LNX, so I'll probably try that out first. And if I'm unhappy with cc65 I'll take a look at all those other tools.

Ok. So is the encrypted loader standard? I.e. could I just take the first 256 bytes after the LNX header from whatever game and put it in my own ROM? And is there a disassembly of a decrypted loader somewhere that I could look at? What I need to know is mainly how much of my own code that will be "automatically" loaded from the cart to RAM, from where, and to where (i.e. what ORG should it have?).

I've been looking at various sources, and from my understanding the whole 64kB physical memory space is seen as RAM, except for the top 1kB which by default contains the system ROM, MMIO, etc. So to make use of the code/data on your cart I guess you'll first have to load it into RAM through the RCART registers(?). That's fine I suppose, but I don't see how my code in an .LNX files actually starts running at boot. When I look at a disassembled system ROM (lynxboot.img) I only see it loading 50 bytes from the cart to $AA-$DB, and when I take a look at what those 50 bytes actually are in e.g. Lynxopoly they don't seem to contain anything meaningful (unless the data is encrypted). Is there any info available on this subject? I.e. what part of an .LNX file is first executed, from what address is it executed, and how has the hardware been set up at that point?

Sorry for the late reply. I've been occupied with some SNES and TurboGrafx projects so I didn't check this thread. Martin's document can be found here. I'm not gonna link to the official AGB programmer's manual since it'd be stupid of me to post copyrighted material on a public forum But I'm sure anyone who wants the document will be able to find it if they search enough - after all, it's been floating around on the 'net since even before the console was released. The comment in general. I.e. that there's nothing more to know than what's in the currently available docs. Maybe that's true (although to me they seem to be lacking info), but they're surely not organized in a way that simplifies finding the information you're looking for.

Thanks. Though what I'm mainly interested in is Mikey / Audio, and that section hadn't been written yet The docs on Bastian's site are the same EPYX docs I was referring to in my OP. They do contain some info but leave out a lot of details. As for Audio, there are no more "details". What might be missing are the extension for the Lynx II. Stereo positions for channels and volume. But you should be careful about using them as the sound on the Lynx 1 is coming without these extensions. If it comes to how to use they to get useful sound, well thats a different story... For Mikey, there is stuff about registers witch is not documented, but not needed. Initilaisation and so on is just defined on how it should be done. period. For a beginner, stay with the examples and the supplied macros and dont fiddle araound with the rest. I think you're making a (common) mistake in saying that, which is to look at the documents from the point of view of someone who already knows all of the information contained in the documents I'll illustrate with a small example: FD25 = Audio Control Bits B7=feedback bit 7 B6=reset timer done B5=enable integrate mode B4=enable reload B3=enable count B2,B1,B0=clock select 7 = linking 6 = 64 us 5 = 32us 4 = 16 us 3 = 8 us 2 = 4 us 1 = 2us 0 = 1us Now imagine that everything you know about the Lynx has been erased from your mind.. Can you honestly say that if you looked at this isolated register description that you would know what the result of changing any of the bits would be? I'm just saying that there are much better and clearer ways of documenting hardware. Nintendo showed it could be done with the AGB programmer's manual, and in the homebrew arena Martin Korth's documents are pretty much the gold standard as far as structure and readability is concerned (IMO).

Thanks. Though what I'm mainly interested in is Mikey / Audio, and that section hadn't been written yet The docs on Bastian's site are the same EPYX docs I was referring to in my OP. They do contain some info but leave out a lot of details.

Is there any comprehensive technical documentation of the Lynx? Stuff like memory maps, I/O register description, graphics format description, ROM format, etc.? Something like these: http://nocash.emubase.de/pandocs.htm http://nocash.emubase.de/everynes.htm They don't need to be fancy HTML pages; plain text will do as long as it contains relevant information. The only docs I've found are the ones written by EPYX(?), wich are....not good