that was a good memory doc! I think I'll email some q's to that author too :^P
>I usually just toss it all into a directory and point Dev. Studio at it,
>that way I can do all the powerful search/sort shit much easier.
since I don't have Devstudio, there does that idea...
I think I'll write some little VB program to do it... I only got an old pir8 copy of VB3.0 tho..hehe..

>Vertical Blank, usually what the NMI is timed to. It's when the scanlines
>retrace the screen vertically, which is a good safe time to update the
>screen, since it won't flicker when you do it.
Uh, ok I remember there being two different interrupt types in the GTE doc (maybe more, but I can't decipher that thing very well), one called NMI (and VBL would be another name for exactly the same thing?) and another 'input', simply called IRQ. What's the IRQ? And, what is the interrupt rate for the NMIs? my guess is 60Hz, which would be a period of 44666 cycles for SlowROM and 59666 cycles for FastROM, and 6/5ths of that on a PAL...?
By the way (this might be related...) how does a game tell whether it's running on a PAL or NTSC SNES, and what is the difference(s)?
(When I ran Mario Allstars on Nlksnes it claimed that 'it isn't designed for your SNES'. hmmm)
I would like to know what the GTE doc is talking about when it refers to the other slash thingies (/SO, /RES etc) but maybe I'll just wait for that other SNES doc you were talking about...

>Nah, 512 at the beginning and 64 at the end of the first block, and it's
>PART of the first block - which means it gets loaded into memory just like
>everything else.
what, are you saying all this header junk is actually part of the ROM image?

>Um, ok. Let's see. I don't care whether you want to join up or not, but some
Ya, we better stick to separate projects.  I'm not ready for Mutex's just yet... =)

>1. Overhead for task-switching... is running anyway if you have Win95, even
>inside a dos-box. AND it's way more optimized than any programmer could get
well, you're probably right, I'm sure it's optimised to hell and gone, but then again, a DOS program is only ONE thread... (isn't it?)

>theirs (and you'll need some, even just a baby form, to run your DOS emu) in
>a million years, since Microsoft has oh, a couple hundred people working
>full-time on it.
Maybe this is the devil's advocate point of view, but I figured the more people you have working on it (more than, say, 5 people) the more inefficient it gets...

>3. Exclusivity is only a problem for the ROM addresses, which yes I have to
>mutex to hell.
ah. mutexing.  A couple years ago I read a book on operating design, I think it talked about those... and I was confused as hell.
>I use MS Visual C++ 5, Developer's Studio 97. Very tight code, probably
>outperforms all previous compilers (including MSVC4.2) by about 30%. Course
>it also costs a couple hundred bucks... unless your employer buys it for
>you... hehe.
Well, I paid $250 US for Watcom 10.6, because a couple months before I'd read a review showing that WC++ on average generates the fastest code... although I don't think it was 30% faster... perhaps VC and WC are on a par by now?

>Anyway, here - have a memory doc, I still have to dredge up the CPU doc.
CPU doc, come to papa!
