--------------------------------------------------------------------------

15. March, 2002   Version 1.10

- There is mainly one big topic in this release: subchannel handling.

  First let me try to explain in an easy way what "subchannels" are for:
  Beside the "real data" in a cd sector, there are also a few extra 
  informations for each sector. That extra informations ("subchannel data")
  are usually used on audio tracks, to give informations about the current
  head position (unlike a data track, an audio track needs all bytes in a 
  cd sector for the audio data, so there is no space left for sync infos or 
  error correction infos... but in the q subchannel there is a track number, an
  index number and even absolute/relative timestamps, so the audio cd player 
  can use that for synchronisation while playing cd audio).

  The subchannels are also present on data tracks, even if no file system
  will need them... and once-upon-a-time game companies had a "great" idea
  for copy protections: usually the timestamp in subchannel data will give
  the position of the playing position... but data tracks don't need that
  info... so why not abuse the data? Why not change, for example, the 
  timestamp of a few special data sectors to some nonsense values? The game
  can read back the subchannel of that sectors, and detect illegal cd
  copies that way (since most cd writers will write correct timestamps, and
  not the "nonsense" ones of the original cd).

  OK, now I can hear the questions of many users, asking "so what's the 
  problem? I only use original games, so I don't care about copy protection
  issues."
  Unluckily that's not true... unlike the psx cd drive, there are some 
  problems reading subchannels on pc drives. The 'official' scsi commands for 
  reading subchannel data will give you not the exact sub q data of a sector,
  the values are usually from a +/- 1 second wrong sector (that's because 
  the command was designed to give only rough position infos for audio playing, 
  nothing else).
  There _are_ vendor-specific subchannel read commands for most drives, but
  the vendors are not giving such informations easily to interested users
  (I am really wondering why... hell, it's my drive, and if it can read such
  data, and if I want to use it to do that, why refuse to give me the
  required informations? And next time when I buy a car, I prolly will not 
  even get the keys for it, pfff).

  So, in the past, users of _original_ but copy-protected psx game cds had 
  to search the net for special game PPF patches (which removed the protection), 
  if they wanted to play such a game in an emulator. Not very nice, isn't it?

  The first emu team which tried to get around that situation was FPSE, afaik...
  FPSE 0.10 was never released, but LDChen (main coder of FPSE) claimed he had 
  some copy-protected games up and running, without any PPF patches (and I  
  have no doubts about that... prolly he had found a command on his cd drive,
  which was reading the subchannel data).

  Well, lately more emu teams were trying to emulate copy protected games
  (to freely quote lu_zero: "Cheats and hacks are bad! Only real emulation
  is the true way!"), and so I (as the creator of this small cdr plugin) was 
  forced to try my luck with subchannel reading as well :)

  "Pain in the ass" doesn't describe my cdr coding sessions... it was a more 
  overall pain, I can assure you ;)
  But with much talks and more tests between the members of various psx emu
  teams (hi to calb, _Demo_ and shunt), I can now proudly present version
  1.10 with subchannel support.

  So, now let's move to the new options:

  1.) there is a mode called "Don't read subchannels". If your game doesn't 
      have a copy protection, use that one. That mode will work like the previous
      versions of my cdr plugin, no loss, no gain.

  2.) a mode called "Read subchannels". Go figure ;) Well, I advise NOT to use
      that mode, ehehe. Confused? Aahhh... lemme try to explain: I've coded
      four different sub channel read modes (one is working on my Pioneer in BE_2
      scsi read mode, one is working on my Teac in combination with the 28_1 mode, 
      one is using the standard scsi "read subchannel" command (gives not the 
      exact values on my drives), and one is only available in W2K/XP (and also
      doesn't give exact values on my drives). But all of them will SLOW
      DOWN the cdrom access (well, the BE_2 mode is kinda OK, but the teac mode
      has the same effect as a FPS limitation to 3 FPS if a game is accessing
      the cd all the time).
      And I've noticed that a randomly accessed subchannel reading of sectors 
      can lead to some wrong bits in the subchannel data from time to time, due 
      to the lack of some error correction... bad thing!
      So, that leads us to the 3. RECOMMENDED mode:

  3.) "Use subchannel SBI/M3S info file". What's that? Easy: the plugin will only
      do the normal, fast data reading (like mode 1), and everytime when a game 
      wants to have subchannel data, the plugin will use the subchannel data stored
      into a file on your harddisk. So, you just have to create a subchannel info
      file of your copy protected game one time, and activate that file in the 
      plugin if you want to play that special game (that's when a frontend like
      ePSXeCutor comes handy, for creating different game configs, ehe :)
      So, it kinda works like my PPF option, but of course you can create your
      own info files, you don't need the help of some cracking crew =)

      How to create such subchannel info files? Easy as well: there is a special 
      button in the cdr config window, which will let you create the files directly
      from your original cd, or (if your drive is not supported by my subchannel
      reading funcs), you can convert a CloneCD SUB file... of course you will
      need CloneCD as well to do that, but it's the only way to get the subchannels
      from a drive not supported by my plugin (and prolly there are many not
      supported drives...)
 
      I support 2 different subchannel info file types: a format which is also used
      by epsxe, called "M3S". This files will ever be 71 kbyte in size, but they
      don't contain _all_ subchannels from a game, just the ones of the minute 3
      sectors... usually that's enuff for psx copy protections, but to be sure I
      made my own file format as well, called "SBI". That one will contain all 
      "nonsense" datas from track 1 of a game cd, so the size will vary (usually it's
      small, though, only 5 - 20 kbytes). It takes more times to create "SBI" files,
      well, so it's up to you :)

  Ok, so you have created the subchannel info file, you did configure the plugin
  to use it... and still the game doesn't work??? Why???
  First: the main emu has to support the new subchannel commands... if it doesn't,
  it will not work. At the time I am typing that text only ePSXe 1.5.1 can be
  used with subchannels, but I am sure that more emus will follow... so stay tuned =)
  Second: There is an option called "Enable subchannel support" in ePSXe 1.5.1 
  (and in ePSXeCutor 1.0.5.1 as well, of course). You have to ENABLE that epsxe 
  option, or otherwise epsxe will NOT use the subchannel data.
    
  Oki... that covers the complex subchannel topic, I think... and now I am off 
  playing Crash Team Racing (PAL) and MediEvil1 (PAL), ehehe ;)

- Ah, well, some more notes (only important to emu coders, I think)
  1. If you want to do a cdr plugin, and you want to know how the new subchannel
     func is defined, or if you want to know he file format of SBI/M3S files,
     you can check out the updated CDR PLUGIN interface specs on my emu development
     site
  2. The plugin now supports the "CDRgetDriveLetter" func... but only in W2K/XP...
     no good working way found in W9X/ME yet... and the "CDRopen" has to be
     called before tyring to get the drive letter.
  3. The plugin now supports the PCSX "CDRgetStatus" func... in a way, at least.
     It will not give ALL wanted status infos, since some of them are hard to get
     without slowing everything down... ah, we will see.
  4. The new subchannel func (and the "CDRgetStatus" func as well) can be used
     by a main emu team to get the current audio play position (BCD coded
     time stamps)... of course only when some CDDA is playing ;)


"Each step I take
 May it hurt may it ache
 Leads me further
 Away from the past
 But as long as I breath
 Each smile on my bleak face
 I'm on my way to find
 Back to the peace of mind" 
- "The Soulforged" by Blind Guardian

--------------------------------------------------------------------------

05. January, 2002   Version 1.9

- Copy & paste from V1.8:
  Another very small update: my cdda funcs are now using a different 
  "stop cdda audio playing" command, since the old code didn't 
  work on all drives :)
  Yup, the 'stop cdda' stuff from 1.8 wasn't perfect as well, so I 
  hope that this version will now work without problems... I've 
  checked it with my Pioneer and Teac drive, and haven't seen any 
  troubles anymore.
   
- And another small bug has been squashed: if you have tried to select
  the "raw" mode in W2K/XP the first time, there were some chances 
  that the cdr config window couldn't get closed (because the plugin 
  demanded that you should also select a scsi reading mode... and of 
  course there are none in the "raw" interface :)
  

"He can remember hearing words of wonder
 'Failure is on the inside'
 so often does he wonder
 how hard it is without a guide"
- "Red is a mean, mean colour" by Steve Harley and Cockney Rebel


--------------------------------------------------------------------------

02. December, 2001   Version 1.8

- Another very small update: my cdda funcs are now using a different 
  "stop cdda audio playing" command, since the old code didn't 
  work on all drives. Thanx to calb for doing tests.

  Btw, only PCSX is using the plugin's cdda funcs right now, epsxe
  1.4 is using mci audio with W9x/ME, and native ioctrl calls
  with NT/2K/XP (and that's not working with external cdr plugins, 
  as you can read in the 1.7 notes)... but, as you can easily 
  figure out, that will change in the future :) 


"Can you shield me
 From the drastic truth?
 Times come and go
 How dull the flow
 All that I hope
 The Unknown knows"
- "The Unknown Knows" by Voivod


--------------------------------------------------------------------------

22. September, 2001   Version 1.7

- Short info: 
  native W2K/XP support without the need for an additional 
  installed ASPI layer.

  _Long_ info (you have been warned ;) :
  Some weeks ago I've installed W2K on my new system (along with
  W98 and Linux), and of course one of the first things I've done
  was checking all my plugins under W2K. 

  Well, the gpus were working fine, the spu had some problems
  (should be fixed, check out V1.11), but the cdr plugin did run
  _very_ slowly in ePSXe. Unplayable. The native internal epsxe 
  W2K cdr plugin did work fast, but, as usual, only on my Pioneer
  DVD drive, and not at all on my TEAC cdrom drive. 

  Well, I suspected the forced ASPI layer was giving me such a bad 
  performance, so I started to code a native W2K iocontrol interface
  on my own.

  It worked... with the same horrible speed as the ASPI layer...
  a game wants to read one (not yet cached) sector, the drive spins 
  up, reads the sector, spins down and giving finally the wanted 
  data... that did take 3 seconds on my Pioneer for one sector, and
  9 seconds on my TEAC... needless to say that it would take hours
  to load a game that way, bah!

  Well, I tried another way, still using iocontrol, but without scsi
  commands this time (using the raw read command)... and, still the 
  same! Okay, finally I've tried a simple FileRead command (that one
  isn't very compatible, it will not give all the psx sector data, 
  but hey, I was desperate :)... and still slow!

  And... I gave up! Well, for the time beings... on IRC lu_zero 
  suggested to try FPSE with the native FPSE W2k cdr plugin, to see 
  if that one has the same troubles on my system. And it worked 
  fine (again only on my Pioneer, the TEAC one was refusing to
  read anything).

  I suspected some kind of conspiracy (hey, if two independed emu
  teams _can_ read fast at least with one of my drives, and I 
  can't... that's an hit for my ego! ;)

  By pure luck I checked lazily my native W2K funcs with FPSE,
  instead of ePSXe... and BOOOOM... suddenly my code also was
  working fast! Even on both of my drives! Started ePSXe again... 
  slow! Started FPSE... fast! WTF?!? Well, finally I've found the 
  reason: if you are enabling CDDA support in ePSXe, the emu
  is communicating directly with the cdrom drive, bypassing
  the cdr plugin... and that's something W2K obiously doesn't like 
  much... BAD, calb, BAD :)

  Oki, lesson learned: if you want to use a different cdr plugin
  (not the native epsxe one) with W2k, you have to disable the 
  epsxe cdda support... at least until epsxe 1.5 is released
  (you better run fast, calb, or I will kick your sorry ass ;)
  Not a big issue, since most games are not using cdda at all.

  And now the good news: since I had done so much reseach, it 
  was easy to finish my native W2K iocontrol support. As a matter
  of fact there are two W2K modes in my plugin, a "raw reading"
  mode, and a "scsi command" one. The raw mode doesn't need any
  vendor specific read commands, hopefully it will work on most
  drives out there. And even better: the performance is increased
  compared to the native epsxe/fpse w2k plugins, AND my TEAC
  drive is working fine as well :)

  Yeah, finally I can sleep well again ;)

  
"On the edge of the rainbow
 Where eagles learn to fly
 All of our dreams, they seemed so clear
 Into the morning
 Into the light of dawn
 We're flying higher than before"
- "Lake of Tears" by Gamma Ray

--------------------------------------------------------------------------

15. July, 2001   Version 1.6

- "Try again on reading error" option. Now you
  can tell the cdr plugin to try the sector reading
  up to 10 times again. Very helpfull with scratched
  CDs (like my Tomb Raider 2 one ;)

- "Use PPF file" option. Some psx games need special 
  patches to work right. Or you want to use special 
  trainers/cheats for your game. 
  In the past you had to create an ISO of that game, apply 
  the patch, and burn the game again. Now you can simply 
  select a PPF file in the plugin config, and the patch will
  be done automatically within the cdr plugin while playing 
  the game... no need to make patched copies anymore :)
  I've made the patching engine very fast, I think, so you
  shouldn't see any performance hits (of course it will not
  _improve_ the performance as well ;)
  Btw, every request for PPF files will be ignored... 
  The plugin supports PPF1 and PPF2 files, but it will
  not check if the PPF file is 'right' for the game you are 
  playing. So take care (or better: take ePSXeCutor/
  PSSwitch/new AdriGUI to create different game configs).
  Big thanx for that idea to JNS... you were right... it is 
  possible :)


"If I could hold on to just one thought
 For long enough to know
 Why my mind is moving so fast
 and the conversation is slow"
- "Barstool Blues" by Neil Young

--------------------------------------------------------------------------

10. June, 2001   Version 1.5

- A rather small update: the interface for getting
  the track informations was handled wrong with
  the previous versions (1.4 or lower) .
  Well, more exactly, my plugin had given the right 
  infos, but not in the same way as all other available
  cdr plugins ;)
  It wasn't noticed because that infos are only used
  on CDDA audio playing, I think, but the keen eyes
  of linuzappz see everything :)


"'Oh please, don't sell me out', 
 said the man with the hammer, hammering the anvil
 'I've been walking on the road of rocks
 and I keep on hammering, keep on hammering, 
 keep on hammering, hammering the anvil.'"
- "Hammer Song" by The Sensational Alex Harvey Band

--------------------------------------------------------------------------

29. May, 2001   Version 1.4

- A few drives are not supporting the "wait til
  ready" command I am using on startup. So I've 
  decided to make an option for turning that waiting
  function off... activate it, if the plugin is only giving
  you a black screen with _all_ of your games on 
  startup.

- A new caching mode, called "Async read". That one
  will give you a few more FPS on MDECs and XA 
  audio, by doing an additional 'intelligent', non-blocking 
  read... 
  I've seen up to 10 FPS faster mdecs that way... not
  too bad... no other cdr plugin is getting an higher 
  speed on my system right now :)
  Big thanx to Roor for suggestions...
  
 
"Hogwarts, Hogwarts, Hoggy Warty Hogwarts,
 Teach us something please,
 Whether we be old and bald
 Or young with scabby knees,
 Our heads could do with filling
 With some interesting stuff,
 For now they're bare and full of air,
 Dead flies and bits of fluff"
- "Harry Potter and the Philosopher's Stone" by J.K. Rowling

--------------------------------------------------------------------------

19. May, 2001   Version 1.3

- My cdr plugin did report the track start address in
  a wrong way to the main emus (it reported the start
  of track 2, when it got asked about track 1, and so on...)
  That's fixed.

- Support functions for PCSX cdda audio playing.
  No other emu is using that functions right now.


"Ballerspiel-Ballerspiel ... zu gewinnen ist mein Ziel.
 Ballerspiel-Ballerspiel ... zu verlieren gibt's nicht viel.
 Hoi-Hoi, Hoi-Hoi, Hoi-Hoi"
- "Ballerspiel" by Abgehrte Telefonate

--------------------------------------------------------------------------

05. May, 2001   Version 1.2

- I knew it... once I've started, I can't stop... sigh ;)
  First of all, I've improved the "read ahead" caching, 
  should be a bit faster now.

- The plugin is now waiting until the drive is reporting
  everything is ready. That will prevent crashes which
  could happen in the past on game startup (mostly 
  after changing a game cd).

- "Cd drive speed limit" option. Maybe your drive will
  doing the reads smoother and less noisy if you limit
  its speed (no differences on my drives, though).
  Not all drives will support this option. 
  
- Note: don't forget to set the correct cdrom drive letter in 
  epsxe... otherwise lockups can happen.

- There will be NO 1.3 version today... REALLY :)


"Who will trade his karma for my kingdom?"
- "Karma" by Kamelot (they have supported me well 
   while coding this plugin :)

--------------------------------------------------------------------------

05. May, 2001   Version 1.1

- Bah...  "don't expect a 1.1 version anytime soon"...
  Funny :)
  Well, after I've got some mails concerning my cdr
  plugin, telling me it doesn't work (crashes or just a few
  frames displayed), I've done some investigations and
  found that older epsxe versions (older than the one I 
  am using currently anyway ;) had a bug in opening
  the cdr plugin... Bad, calb, bad! ;)
  Well, I've added some "security" code, so now the 
  plugin should work with all epsxe versions...
  
- Don't expect a 1.2 version anytime soon... ;)


"I don't believe that my story is set
 nothing is destined or blatant"
- "Wings of Despair" by Kamelot

--------------------------------------------------------------------------

04. May, 2001   Version 1.0

- That's the first release, so don't expect much
  version news :)
  Please check out the readme for details.

- Mmm... and don't expect a 1.1 version anytime 
  soon. The plugin is complete and bugfree ;P
  Well, maybe if some main emu author comes
  up with a fancy idea for the psx cdr emulation...
  we will see :)


"Where is all the magic gone
 lost behind or lost along
 a victim of the pulse of our society
 don't you miss the ancient times
 the riddles and the subtle signs
 a relative perspective on reality"
- "The Spell" by Kamelot

--------------------------------------------------------------------------
