Meteor Blaster DX Reprint

[spenoza]

The guy who designed the original CD layout was a classical music buff.

And CDs are still the best way to listen to classical recordings. A lot of people rave about the quality of vinyl, and that's just because most pop and rock on CD is mastered for loudness and constant volume instead of for quality. Good classical recordings on CD prove the quality (and relative superiority) of CD digital audio, including the incredible dynamic range. Of course, you'll want a quality CD player with good, high quality amps and speakers, too...

[CrackTiger]

I got a shipped notice.

[roflmao]

Mine arrived today!  Durham, NC!? I didn't know Mindrec was only an hour and a half away.  Cool.

[Arkhan Asylum]

Mine arrived today!  Durham, NC!? I didn't know Mindrec was only an hour and a half away.  Cool.

Isn't that where Fragmare is at?

BT is up in Canadia, I thought.

[Bt Garner]

Got mine in the mail yesterday too, but didnt check the mail till early this morning.

This isn't a complaint, but something on the package and/or CD stating that this is a reprint would have helped differentiate this from the original CD-R version a little better. Aside from the clear case and Ximati ad on the inside insert, there doesn't appear to be a difference between the two. Although I haven't compared them side by side yet and merely going by memory.

There is not a difference, other than the tray and insert.

Basically, the art format that the CD pressing house needed was one of the higher quality ones (Quark), and the original files were in that format.  Not having access to Quark, nor wanting to shell out cash (or a further delay in the project) to update the files, I just let them go as is.

[Bt Garner]

Here are the numbers so far ....

I received about 50 pre-orders. (and the pre-order page will be open for a few more days).  70% have been shipped at this point -- I have tracking numbers, but felt it was more important to get more orders out than enter the numbers in paypal.  Those numbers will be entered later, but you'll probably already have your CDs by then.

The last batch of domestic pre-orders (10) will go out on Monday or Tuesday, then the final batch of pre-orders (the international ones) will go out later in the week.  The latter ones need to go to a real post office, and not a satellite branch like I have been using.

US orders have been from all over: CA and NC have the most (with 3 each).  International orders have come from Canada, Spain and France.  Once the pre0orders are taken care of, I will download all the orders and make a google map to show where the orders were shipped to.  I will only use zip codes and not addresses.

I actually ran out of shipping envelopes, so 2 orders still have to be packaged up.  When your order is packaged up you get the "In Process" notice.

I also had to up the shipping costs via paypal since they were basically at a break even point for some, and a losing point for others.  Why it costs $2.75 for 2 CDs to ship, but $5.85 for 4 is beyond me.  Oh well, just another discount that folks who ordered early got to take advantage of.

I also found a case of old MB cases (no CDs), so if anyone really wants a white tray to replace the clear one, they will be available soon.

[Mishran]

Got mine in the mail yesterday too, but didnt check the mail till early this morning.

This isn't a complaint, but something on the package and/or CD stating that this is a reprint would have helped differentiate this from the original CD-R version a little better. Aside from the clear case and Ximati ad on the inside insert, there doesn't appear to be a difference between the two. Although I haven't compared them side by side yet and merely going by memory.

There is not a difference, other than the tray and insert.

Basically, the art format that the CD pressing house needed was one of the higher quality ones (Quark), and the original files were in that format.  Not having access to Quark, nor wanting to shell out cash (or a further delay in the project) to update the files, I just let them go as is.

As I said, it wasn't a complaint and your reasoning is valid. I did notice the "Dev/Sig Edition" and the 2013 mark on the title screen which is great. I'm assuming you used the Signature Edition insert too since it does differ from my original release insert.

Overall, everything is great and the inclusion of the 5th ship is cool too. Thanks for rereleasing it for us. Out of simple curiosity, was there any changes made to loop and implode on the disc?

[Duo_R]

If implode changed I would have got the 2 pack. Thanks BT for releasing this!

[Bt Garner]

Got mine in the mail yesterday too, but didnt check the mail till early this morning.

This isn't a complaint, but something on the package and/or CD stating that this is a reprint would have helped differentiate this from the original CD-R version a little better. Aside from the clear case and Ximati ad on the inside insert, there doesn't appear to be a difference between the two. Although I haven't compared them side by side yet and merely going by memory.

There is not a difference, other than the tray and insert.

Basically, the art format that the CD pressing house needed was one of the higher quality ones (Quark), and the original files were in that format.  Not having access to Quark, nor wanting to shell out cash (or a further delay in the project) to update the files, I just let them go as is.

As I said, it wasn't a complaint and your reasoning is valid. I did notice the "Dev/Sig Edition" and the 2013 mark on the title screen which is great. I'm assuming you used the Signature Edition insert too since it does differ from my original release insert.

Overall, everything is great and the inclusion of the 5th ship is cool too. Thanks for rereleasing it for us. Out of simple curiosity, was there any changes made to loop and implode on the disc?

The Loop included with the initial MB was V1, this has V2 (basically Loop with powerups).  Implode Caravan version is the same as the original MB release (not the same as the version on the Implode CD, however).

I made my son (pushing 11 years old) play Loop v2 the other night, and after one game his reply was "I don't like you."

[esteban]

I made my son (pushing 11 years old) play Loop v2 the other night, and after one game his reply was "I don't like you."

Hahahahahahahahaha. That's awesome.  

My daughter felt similarly when I begged her to give Timeball a chance. I like the game and wanted her to appreciate it, too.

Nope.

[ParanoiaDragon]

Here are the numbers so far ....

I received about 50 pre-orders. (and the pre-order page will be open for a few more days).  70% have been shipped at this point -- I have tracking numbers, but felt it was more important to get more orders out than enter the numbers in paypal.  Those numbers will be entered later, but you'll probably already have your CDs by then.

The last batch of domestic pre-orders (10) will go out on Monday or Tuesday, then the final batch of pre-orders (the international ones) will go out later in the week.  The latter ones need to go to a real post office, and not a satellite branch like I have been using.

US orders have been from all over: CA and NC have the most (with 3 each).  International orders have come from Canada, Spain and France.  Once the pre0orders are taken care of, I will download all the orders and make a google map to show where the orders were shipped to.  I will only use zip codes and not addresses.

I actually ran out of shipping envelopes, so 2 orders still have to be packaged up.  When your order is packaged up you get the "In Process" notice.

I also had to up the shipping costs via paypal since they were basically at a break even point for some, and a losing point for others.  Why it costs $2.75 for 2 CDs to ship, but $5.85 for 4 is beyond me.  Oh well, just another discount that folks who ordered early got to take advantage of.

I also found a case of old MB cases (no CDs), so if anyone really wants a white tray to replace the clear one, they will be available soon.

3 from Cali huh?  I wonder who the other 2 are, maybe 1 of them is Charlie MacDonald.  I can't think of any other Californians I know of.  There's one I use to know, Art Agressior or something like that, but I haven't talked to him in ages.

[GohanX]

North Carolina is where it's at!

I mean, Cali is a lot bigger, so that means NC has more Meteor Blasters per capita.

[NightWolve]

What is a post-gap for one track is also the pre-gap for the next.

Hah, yes. I remember finding that out and thinking wtf???

Yeah, they wind up in the same position (a waste of space in my book), but at least a post-gap doesn't cause the complications a genuinely flagged pre-gap does when it comes to track type transitions (audio to data and vice versa). I remember all the damn read errors I used to get when trying to rip a NEC disc in file-per-track mode using CDRWIN, ISOBuster or whatever else. Nothing could do it automatically. Eventually I learned how to use CDRWIN's "Sector Selection" option where you can specify a Start and End LBA to rip a track. So for track 1, Start=0 and End=Track 2's LBA minus 3 seconds (225 sectors), etc. Repeat for track 2, but minus 2 seconds (150 sectors), etc.

I understand now why reading the whole disc in RAW mode worked for every program with no read errors. You don't set the sector type filter flag in the SCSI/MMC Command block in that case. It was years later that I figured this out, but it took developing something like TurboRip to understand it. So what's happening is when you're just asking to read track 1 as an audio track, the program sets a filter flag for only audio sectors and it assumes track 1 ends one sector less where track 2 begins, so it just reads all the way... Well, with NEC discs, you got that damn pre-gap there, and the 1st second of the sectors are flagged as type audio, no problem there, but the last 2 seconds are flagged as type data, so THAT'S where the program will fail out with a read error! When it hits that point... I used to think the sectors in that area were unreadable, but I finally figured it out! That might be true for REALLY old, shitty CD drives from the '90s (should be rare), but yeah, those sectors should be perfectly readable!

Why even have a post-gap cue sheet command. And not all burning software treats it the same.  Most burning software puts the post-gap command of the last track as the pre-gap for the next. If you use both, it's probably just a gamble as to how each burning software treats it at that point. Might create a third index (supposedly legal) on the track and pad with 0x00. As far as post-gap goes, nothing in either red book or yellow book docs ever mentioned it. So I just chalk it up to some legacy cue sheet command or some such crap.

I would think it's somewhere in Yellow Book, the official version, but you can find info on page 18, section 20 of the ECMA-130 PDF which is the freely available version of the Yellow Book format. This stuff:

Track structure of the Information Area
...
For the purpose of linking Information Tracks in the Information Area, these tracks may have:

a) Pause : A part of an Information Track on which only control information but no user data is recorded.

b) Pre-gap : A first part of a Digital Data Track not containing user data and encoded as a Pause. It is divided
into two intervals:
- first interval: at least 75 Sections (at least 1 s) coded as the preceding track, i.e. the Control field
(see 22.3.1) of the q-channel (see 22.3) and, in case of a preceding Digital Data Track, the setting
of the Sector Mode byte are identical with those of the previous Information Track;
- second interval: at least 150 Sections (at least 2 s) in which the Control field of the q-channel and
the setting of the Sector Mode byte are identical with those of the part of the track where user
data is recorded. In this interval of the Pre-gap the data is structured in Sectors.

c) Post-gap : A last part of a Digital Data Track, not containing user data, and structured in Sectors. It has the
length of at least 150 Sections (at least 2 s). The setting of the Control field of the q-channel and
the setting of the Sector Mode byte are identical with those of the part of the track where the user
data is recorded.

I do remember the red book and yellow book documents stating that you can more then two indexes to a track (whether CD players do anything with it, I dunno. Never tried to test it).

Yeap, you can have 99 tracks and each track can be subdivided from 00 to 99. From the same document:

22.3.3.2 INDEX field
This field contains an Index specifying the subdivisions of an Information Track.

Index 00

This value of the Index indicates that the Section is coded as a Pause. The total length of the Pause corresponds to the number of consecutive Sections with Index set to 00.

Index 01 to Index 99

These values specify the indexes of the subdivisions of that part of an Information Track that contains User Data. The first subdivision shall have Index 01. Consecutive subdivisions shall have consecutive Index values.

The Index field of the Lead-out Track shall be set to 01.

You gotta read and process the Q subchannel data per sector (audio/data) to know what's going on for this stuff. Processing this in a program like TurboRip translates to the 16 byte "C" structure below. I use a MMC1 command to read the Q data of the sector to load it up. Quick example: say you're reading the warning audio track 1 of a mixed-mode NEC game disc. Towards the last 3 seconds, you'll find that the TrackNumber field will have changed from 1 to 2 and the IndexNumber will go from 1 to 0, hence, you will have detected a pre-gap that belongs to track 2, the next track, etc. So that's how you'd know you're at the true final LBA for track 1. Normally, you look at the next track's LBA from the TOC and subtract 1, but this pre-gap crap added complications to where you must read sectors and the subchannel data to properly detect the true stop/end LBA of a track. That's why I hate the concept and don't see much use for it... Add to the fun that most drives convert the BCD to HEX for you, some don't, so after > 09 you gotta be checking for that when it comes to this Q data.

Code Select Expand

struct SUBCHANNEL_SUBQ_DESCRIPTOR {
    BITS ADR    : 4;
    BITS CONTROL : 4;
    BYTE TrackNumber; // Warning: CD Device inconsistency in returning Hex or BCD values
    BYTE IndexNumber; // Coding must do BCD/HEX checks before determining data is invalid
    BYTE Min;
    BYTE Sec;
    BYTE Frame;
    BYTE ZERO;
    BYTE AMIN;
    BYTE ASEC;
    BYTE AFRAME;
    BYTE CRC1;
    BYTE CRC2;
    BYTE Reserved1;
    BYTE Reserved2;
    BYTE Reserved3;
    BITS Reserved4 : 7;
    BITS PSubCode  : 1;
};

I will send you an email with a text document explaining things as I see them. PM me your e-mail, please.

Sure, just click my profile, the E-mail is visible. If you had PM'ed me, I would've gotten an E-mail too.

P.S.

If you have the official Yellow Book PDF, or the others after that, by all means, send away. ;) It could help TurboRip in the future. Been looking for that, but I've managed enough with the EMCA stuff and what the T10 group releases.

You can have more than one index per track. This was used (for example) to allow you to seek to a particular movement in a symphony. The entire symphony would be recorded as one track, with different movements as indexes in the track. The guy who designed the original CD layout was a classical music buff.
(Which, incidentally, is where the size of a cd comes from. It had to have enough space to hold a particularly long symphony, because he didn't want to have to change the disc.)

Yeap, I had just read about that a few days ago (the symphony movements basis for the idea). I knew what the purpose of index 00 was with an audio track, you could put an announcement that normally gets skipped over when you're using the Back/Forward track selection buttons on a CD player. I recall actually seeing this in action; the current track is playing and when it gets towards the end, the announcement or whatever begins for the next track, you also have a negative time countdown to when said track is about to start, etc. However, I was puzzled about 5 indexes I saw on a PC-FX data track some time back (something David Shadoff reported to me) and I didn't know what further or useful purpose that could provide. Until I get TurboRip to work with such a disc, I can't certify it for use with them.

Anyhow, when it comes to audio tracks and CD players, I would wager the way it works is you use the forward seek buttons (not the track skip) and when it hits a change in the index number flag (it can only increment by one), it probably stops seeking forward even as you're holding it down and playing resumes. I would guess then you have to release and press it down again, let it seek forward some more and if it hits another increment of index number it stops seeking and plays normally, assuming it doesn't get to the end...

That idea reminds me somewhat of AMS (Automatic Music Sensor) or whatever it was called for cassette players (anybody remember those??). If you leave 2-3 seconds of blank space before recording the next song, you would have decent seeking capability. When you press the forward button and it stays down, it'll forward the tape and if it detects those 2-3 seconds of silence, the button will pop up and playing will resume, etc.

Anyway, I never saw a music CD that took advantage of this... Of course, like this list of hidden songs/tracks in the pre-gap, it's something I could've easily missed even if it was there. Since you can have 99 tracks, you might as well just put the next symphony as its own track making it always fully accessible with the track select/skip buttons and not having to waste time with seeking, etc. You can see why it didn't get used much, if ever, even though it was implemented cause it seemed like a good idea at the time to the designers...

Not really. There is a reason the p-q bits have to be set that way....

Well, we'll have to agree-to-disagree on the value or importance of "decorative" pre/post-gaps when it comes to audio/data track transitions, much less the different flagging of sector type within them. I see all the negative issues/problems that this concept/idea caused and I can't really think much of a benefit...

I did not mean that the pce ignores the error correction

OK, you had me worried there. If I read your original point back, it sounded that way, saying the PCE doesn't check tracks closely, that it ignores the checksums (AKA EDC codes ?), etc. You were trying to point out why you think our burned CD-R discs work anyway, even though they're not totally accurate with regards to this extended 3 second pre-gap issue. But the reason it doesn't care how well that pre-gap is formatted is because, a) it's supposed to be ignored in principle, b) the TOC only ever has the LBA of the first sector that's flagged as index 01. The PCE finds the first data track in the TOC, gets the LBA and wherever that points to is where it boots. As far as it cares, that 3 second pre-gap belongs to track 1 (the warning audio), and not track 2:index 01 where it booted, where the TOC led it to...

Anyhow, this is not out of lack of thoroughness, not checking things too closely. It's natural. Ultimately, my view is this gap crap is "decorative" for track type transitions and hence my feeling that the software at the pressing plant shouldn't care that deeply about how a pre-gap was formatted as far as proper flagging of sector type, etc. It should be good enough that 3 seconds of pre-gap was specified, indexing was all set to 0, and one sector type was chosen for formatting, etc.

There's only one problem with that. You may have either a pre-gap or a post-gap, but not both.

Hmm, I never had a problem burning such a CUE file with both. True, I'd have to examine the disc after it is burned to see exactly how the software implemented it if I wanted to know. CDRWIN and ImgBurn both accept such a CUE file. Sounds like CDRDAO rejects it, your choice software for burning ?

Well, looking at CDRWIN's Help file, it specifies that only one PREGAP command is allowed per track and it must appear *before* any INDEX commands. While POSTGAP commands must appear *after* any INDEX commands, one-time use also. Makes sense. Logically, I see no reason to disallow this and I never saw anything about it in the ECMA or MMC docs I've had - notice, if it was true, it would contradict the rule I posted earlier if you could not use a post-gap when transitioning from audio to data and right back to audio, etc.

Anyway, since the same 2 seconds of space will be created whether one uses a pre-gap command with the next track or a post-gap command at the end of the prior one (in our NEC situation), the LBA offsets are maintained, so it won't change the TOC. What will change is the subchannel data; the track/index fields and what the sectors are flagged as, audio or data (in our situation of a NEC disc), etc.

Also, just for completeness, if you use Index 0, you may not have a pre-gap.

Correct, that'd definitely be a contradiction/confusing if allowed. If you use the INDEX 0 command, you're asking to read the "pre-gap" data from the track file itself (That's almost verbatim from CDRWIN's Help file). While a PREGAP command will burn in a new Index 0 using undefined data generated by the software and the track file will come after. But yeah, that's a genuine mistake.

Please keep this one simple fact in mind: Burning CDs is largely a software matter.

Without access to the source code for *all* the software, things may be happening that you don't see. The data can be modified by the control program, the cd drivers, and the cd burner firmware. Not all pieces play by the same rules.

Certainly, I agree, no disagreement there. Never was. You answered my feeling though that the 3 seconds of pre-gap having sectors flagged half data/half audio probably wasn't the reason for the problem with the pressing plants. I have an idea for solving it if was, though. Something like: 1) Burn a CD-R like you normally do, following the basic rules, 2) Use CloneCD and rip it back in "RAW 96" mode, 3) Examine the .sub file and calculate where that 3 second pre-gap begins, 4) and basically, for 75 sectors, you'd have to flag them as audio (they'll be set as 'data'). You *could* do this, but it'd be tricky, maybe even write a simple "C" program to do it programmatically each time. You get the idea... So, quite a pain in the ass if you *had* to do it... When done, you'd obviously burn that edited disc image back using "RAW DAO 96" mode and that would be the CD-R to send to the company, etc.

(Totally off topic, I know, but useful info for us tech heads possibly)

I made my son (pushing 11 years old) play Loop v2 the other night, and after one game his reply was "I don't like you."

Heh.

I received about 50 pre-orders.

I must say, I am impressed at your sales figures already for this and a reprint at that. If I thought one day, "I know, I'll make an asteroids-like game that I can sell", I just wouldn't believe I could find somebody that'd wanna buy it. Download it off of me, sure, but to actually pay me money, that thought never would've entered my mind... Congrats, you did it though! ;)

[NecroPhile]

"Made in C, eh? N, eh? D, eh?"

[OldMan]

Okay. I snagged the pdf, and will read over it very carefully. Maybe I can finally get a real explanation of what those p-q channel codes actually do.

From looking at a bios disassembly, I can tell you that the q code is how bios recognizes a data track. It will boot the first data track that it finds, but there may be more than 1 on a disc (in seems a single data track may also have multiple indexes, afaik). It actually doesn't use the TOC to determine where to boot from.

I don't remember much about actually trying to rip individual tracks, other than it usually kicked up an error. I believe it always occurred 2 sec before the data track started (which would be where q changes), but once I found out ripping as an entire image in raw mode worked, I quit trying other things <hey, I was young and impatient>
..................................................
An interesting side note for you: Nero 6.0.1 appears to be able to set the p-q codes correctly; it recognizes the change from audio to data tracks correctly. Unfortunately, it has an off-standard way of using cue sheets...

And speaking of wastes of space.....the 8-14 encoding on cd and the other error correction stuff mean only about 1/2 of what it burned is actually real data. Granted, it allows great error correction; but it does remind me of something one of my professors once said: You can get nearly 100% error correction simply by sending the message 3 times. Two matches wins for any byte. Guess just duplicating the information twice would have been too easy

[PunkCryborg]

got mine today, thank you so much! https://www.pcengine-fx.com/forums/index.php?topic=5360.msg299097#msg299097

[turboswimbz]

Got mine too. THanks!

[NightWolve]

Okay. I snagged the pdf, and will read over it very carefully. Maybe I can finally get a real explanation of what those p-q channel codes actually do.

What you also would wanna check out along with that is the last MMC1 document.

http://www.13thmonkey.org/documentation/SCSI/mmc-r10a.pdf

There's stuff in here from both Redbook and Yellowbook, plus the SCSI commands on how to operate a CD drive. Later versions after this one deal with enhancing the instruction set and then on to DVD drives. But this one is the last, up-to-date one for CD. If one wanted to master the CD format and how to read it properly, that's the PDF that you'd want! Burning is another matter...

From looking at a bios disassembly, I can tell you that the q code is how bios recognizes a data track. It will boot the first data track that it finds, but there may be more than 1 on a disc. It actually doesn't use the TOC to determine where to boot from.

Right, it must find the first data track... What better way than to look in the TOC for the first track flagged as type 'Data', obtain its LBA, move the laser to it and begin reading there to boot ?? Pretty sure this is what David Michel told me. The only other way would be much, much slower... You start reading sectors at LBA 0, specifically, the Q subchannel data of the sector (like you're saying), until you hit one that is of type data... You'd have to read past about 8 MBs of that warning audio track and you would hit that pregap too...

You're suggesting it scans sectors from the beginning of the disc if it's not using the TOC to jump directly to the LBA of the 1st data track found there. CD games would boot much slower... I mean, the first thing any CD player does (even a plain ole audio one) is load the CD's TOC, that's how it knows how many tracks there are and what allows it to skip/jump forward to any of them, etc. The logical thing to do is after loading the TOC, is loop through the tracks, find the first one that is flagged as Data, not Audio (the TOC only tells you audio or data - whether the data is mode1, 2, form 1, 2, etc. you have to detect that from the sectors), fetch the LBA and jump to it (move laser to position), read/boot, etc.

EDIT: You're saying the BIOS shows you "q-code" usage, etc. right ? OK, note: Page 19 in that new PDF I linked you:

3.1.41. Table of Contents (TOC) - The TOC has information on the type of session and the starting address of the tracks. This information is encoded in the Q sub-channel in the lead-in area.

The TOC is encoded in the Q sub-channel of the lead-in area, so that's what you must be seeing... Agreed ?

(in seems a single data track may also have multiple indexes, afaik)

Yeah, I learned that it's true for the PC-FX since David Shadoff was nice enough to send me a CloneCD image of a game that was burned with 9 indexes... It's called, "Super PCEngine Fan Deluxe - Special CD-ROM Vol.1" and track 5 is of interest. From the CCD CUE file:

TRACK 5 MODE1/2352
   INDEX 1 13:51:56
   INDEX 2 13:58:45
   INDEX 3 14:01:12
   INDEX 4 16:12:59
   INDEX 5 22:43:38
   INDEX 6 28:16:20
   INDEX 7 29:53:41
   INDEX 8 34:04:26
   INDEX 9 34:29:34

Hope that never happened with any PCE/TG-16 CD... He was helping me improve TurboRip while archiving all his originals and discovered this. I did upgrade TurboRip somewhat by fully supporting SPTI, so it won't need any stupid ASPI DLLs for Windows NT/2K/XP/Vista/7/8, etc. and beyond, but I stopped there. I still have to develop a strategy for analyzing this Q subchannel data to be able to properly handle multiple indexes. I actually hardcoded the 03:00 and 02:00 rule of NEC discs since I thought that was always how it was done... That was before I knew you could actually detect indexes, unfortunately... But yeah, basically, he gave me the *best* development disc to use for when I get back to fixing TurboRip. I burn that image back with CloneCD and I try to read it back, detect all that indexing properly and thus build a CUE file that reflects it. That's the idea.

I don't remember much about actually trying to rip individual tracks, other than it usually kicked up an error. I believe it always occurred 2 sec before the data track started (which would be where q changes), but once I found out ripping as an entire image in raw mode worked, I quit trying other things <hey, I was young and impatient>

Yeah, that was hell back then. TurboRip does it right, but only for NEC discs since I hardcoded that 3/2 second rule... Like you said earlier, a certain level of laziness or lack of thoroughness by programmers so they didn't fully take into account what needed to be done to handle mixed-mode CDs...

An interesting side note for you: Nero 6.0.1 appears to be able to set the p-q codes correctly; it recognizes the change from audio to data tracks correctly. Unfortunately, it has an off-standard way of using cue sheets...

Ah, that's good. I used to use that program cause it came with one of my DVD burners. It was OK, I even incorporated their ASPI DLL for TurboRip. Something was up with it though and I'd have to pay to upgrade to their latest version, so I just use ImgBurn now for burning. Works well and is free.

And speaking of wastes of space.....the 8-14 encoding on cd and the other error correction stuff mean only about 1/2 of what it burned is actually real data. Granted, it allows great error correction; but it does remind me of something one of my professors once said: You can get nearly 100% error correction simply by sending the message 3 times. Two matches wins for any byte. Guess just duplicating the information twice would have been too easy

With MODE1 sectors and all that ECC stuff, right ?? Yeah... I like that they just went simple with the DVD. 2048 bytes of data, and 4 bytes of EDC/CRC32 and THAT'S IT! No more games/ideas at the sector level. You can organize what you want on it at the file system level, etc.

[roflmao]

I made my son (pushing 11 years old) play Loop v2 the other night, and after one game his reply was "I don't like you."

Loop is the only one I haven't figured out yet.  I'm sure I'' get it once I dig into the manual, but all the others were so intuitive I was able to jump right in. 

This set for $25 is an amazing deal.  There is a ton of great gameplay to be found in these two discs.

[OldMan]

Yellowbook standard isn't applicable here. PCE cds predate that.

What better way than to look in the TOC for the first track flagged as type 'Data', obtain its LBA, move the laser to it and begin reading there to boot ??

Except thats not what I'm seeing in the code. The cd electronics has a register the holds the pq-code for the current frame. Bios monitors that register (and &'s it with a mask ) looking for a particular bit to be turned on. Then it starts loading into memory, and starts executing code when the read finishes.... (it's a 1 sector read, the ipl)
Please note, it is not requesting to read a particular sector. It checks the bit, and then starts reading....

As far as I can tell, it doesn't read the TOC until -after- it has checked for a bootable cd.
I'll keep looking into the bios, though. I haven't drilled all the way down into all of the routines to see what is going on. At the time, I was more interested in how it read the ipl.
And I'm not sure that the 'pause' areas aren't skipped automatically by the cd hardware. There are some funky timing loops in the bios...(fwiw, a sector seems to be read on basically a byte-by-byte basis, with timing loops to allow the electronics to decode things between sectors)

[ParanoiaDragon]

Woooo-woooooooo!  Got mine!

[DragonmasterDan]

got mine yesterday

[JoshTurboTrollX]

Got mine yesterday as well!! WOOOT!!

[T2KFreeker]

Here are the numbers so far ....

I received about 50 pre-orders. (and the pre-order page will be open for a few more days).  70% have been shipped at this point -- I have tracking numbers, but felt it was more important to get more orders out than enter the numbers in paypal.  Those numbers will be entered later, but you'll probably already have your CDs by then.

The last batch of domestic pre-orders (10) will go out on Monday or Tuesday, then the final batch of pre-orders (the international ones) will go out later in the week.  The latter ones need to go to a real post office, and not a satellite branch like I have been using.

US orders have been from all over: CA and NC have the most (with 3 each).  International orders have come from Canada, Spain and France.  Once the pre0orders are taken care of, I will download all the orders and make a google map to show where the orders were shipped to.  I will only use zip codes and not addresses.

I actually ran out of shipping envelopes, so 2 orders still have to be packaged up.  When your order is packaged up you get the "In Process" notice.

I also had to up the shipping costs via paypal since they were basically at a break even point for some, and a losing point for others.  Why it costs $2.75 for 2 CDs to ship, but $5.85 for 4 is beyond me.  Oh well, just another discount that folks who ordered early got to take advantage of.

I also found a case of old MB cases (no CDs), so if anyone really wants a white tray to replace the clear one, they will be available soon.

3 from Cali huh?  I wonder who the other 2 are, maybe 1 of them is Charlie MacDonald.  I can't think of any other Californians I know of.  There's one I use to know, Art Agressior or something like that, but I haven't talked to him in ages.

You can count me as one of those California orders. Southern California, to be exact. Still hasn't arrived yet though. ;)

[Bt Garner]

You can count me as one of those California orders. Southern California, to be exact. Still hasn't arrived yet though. ;)

The last major batch of domestic CDs went out yesterday (although a few more have trickled in since then).

Those and the international orders will go out on either Thu or Fri.

[mukanshin]

Mine arrived Monday in Dallas. Most of my time at home has been spent playing it.

I'm on the mailing list but I haven't been able to make posts in the past because I have a Yahoo address. If bt or someone else here can override that, I'd sure appreciate that. The first part of the address is snailboy1.

[TheClash603]

Just got back from Atlantic City to see the package waiting on my doorstep.

Won't get to play until the weekend, but looking forward to it!

[Bt Garner]

The last of the pre-orders will go out tomorrow.  This includes 6 international orders, and 2 domestic orders that came in over the last few days.

With this last batch of orders, the re-release has also paid for itself (just barely).  I also now have 250 CD mailers too that were part of the COB, I'm sure if not used for MB2013, they will be needed for the next effort:

[GohanX]

I got mine yesterday! Joy!

[NecroPhile]

.... the next effort:

Mmm, shewty.  Sign me up! 

[jperryss]

Got mine today! 

[esteban]

.... the next effort:

Mmm, shewty.  Sign me up! 

Heck yes! 

[hoobs88]

Mine arrived today but the packaging is the same as the original. How will I be able to distinguish them apart?

[shubibiman]

Thanks for the update ;)

[Bt Garner]

Mine arrived today but the packaging is the same as the original. How will I be able to distinguish them apart?

clear cd tray versus white cd tray

[esteban]

I forgot to mention that I received my games earlier this week. Hopefully I'll have some time to play both Implode and Meteor Blaster with my daughter this weekend.

Is the Implode mascot a distant relative of Monsieur Lemming, by any chance?

[T2KFreeker]

Nice man. Very nice. Games arrived and were packaged well. I appreciate it. Now you got me wondering about Xymati though. I am hoping that this will be getting a Turbografx/PCE release? I likes shooters like that.

[Bt Garner]

Is the Implode mascot a distant relative of Monsieur Lemming, by any chance?

No idea -- he was completely the creation of the guy who did the packaging art.  Contrary to popular belief, he shares no resemblance to me.

[roflmao]

No idea -- he was completely the creation of the guy who did the packaging art.  Contrary to popular belief, he shares no resemblance to me.

I always imagined you as a redhead wearing a pink bathing suit.

[tpivette]

Damn, missed out on the pre-order discount. Oh well, I will still be ordering this shortly... $30 for both games is still a damn good deal!

Is Implode a re-release as well? If not, is it a pressed disc, or CDR?

[Bernie]

Implode is a pressed disc, and IMO way more fun than Meteor Blaster. 

[NecroPhile]

Mine arrived today but the packaging is the same as the original. How will I be able to distinguish them apart?

Besides the obvious tray difference, they're similar but not identical:

-  slight color shift, most obviously on the spine title
-  new version's font is less bold and less condensed (enough to shift line breaks even)
-  new disc's label is printed further into the hub area
-  new disc's printing is much clearer and easier to read (small white text)
-  one of the three screen shots on the case back is different
-  "Made in Canada" was added to the case back

[NightWolve]

Yellowbook standard isn't applicable here. PCE cds predate that.

Meh, I would've responded sooner, but I lost a post a few days ago - browser crash. Anyway, you didn't at all find saying this counter-intuitive, that PCE CDs somehow predate Yellowbook ?? What else would they be following ?? They use Yellowbook mode 1 data sectors, they're not anything else, then you have the mixed mode CD layout, like the extended 3 second pregap rule when it comes to track type transitions that we were previously talking about, all of which comes from Yellowbook... Moreover, a CD-R is based on Orangebook which is meant to allow everyone to burn Redbook or Yellowbook type discs, and CD-Rs in fact work on all NEC systems (burning software would only know how to do Yellowbook, not something custom NEC might've done) which also support CD+G discs, though that apparently came with an updated revision of Redbook.

Yellowbook is an extension to Redbook that was developed in 1985 by Sony and Phillips because the industry wanted reliable digital data storage (audio discs have no CRC checking) etc. You'd have to believe Hudson/NEC created their own data sector format here... No, they got licensing from Sony/Phillips obviously... I suspect you've been misled by inaccurate information, possibly by Wikipedia or other places... I discovered it because I was googling around enough trying to understand why you would've said this. So first note on the Compact Disc page, they have the correct information:

For the first few years of its existence, the CD was a medium used purely for audio. However, in 1985 the Yellow Book CD-ROM standard was established by Sony and Philips,

HOWEVER, on the CD-ROM page, they have a clear error:

"the Yellow Book, created by Sony and Philips in 1988, was the first extension of Compact Disc Digital Audio."

In actuality, all that happened in 1988 was that the ISO and ECMA groups adopted Yellowbook as a standard (it was also extended, CD-ROM/XA, by adding "mode 2" type data sectors). They gave out free information with that standard too, whereas normally you had to pay Sony/Phillips to get a full copy of Yellowbook. Anyhow, it had in fact been around for 3 years, available for licensing from Sony/Phillips, so plenty of time for NEC to have developed a system around it. Wiki says that NEC released their first CD add-on unit in 1988 (I'm trusting it here), so yeah, that's 3 years later... That timeline fits! If both Yellowbook and NEC's CD unit were released in 1988, NEC would've had to work pretty damn fast to support it... But yeah, you can verify that many documents state 1985 as the year Yellowbook was developed (it seems the 1988 error is widespread though). I just kept digging further which is how I found this error because reading that both were released in 1988 just didn't make sense; NEC couldn't have worked that fast so somebody had the wrong year. Sure enough, it was whatever wiki-knucklehead that edited that CD-ROM page.

Except thats not what I'm seeing in the code. The cd electronics has a register the holds the pq-code for the current frame. Bios monitors that register (and &'s it with a mask ) looking for a particular bit to be turned on. Then it starts loading into memory, and starts executing code when the read finishes.... (it's a 1 sector read, the ipl)
Please note, it is not requesting to read a particular sector. It checks the bit, and then starts reading....

As far as I can tell, it doesn't read the TOC until -after- it has checked for a bootable cd.
I'll keep looking into the bios, though. I haven't drilled all the way down into all of the routines to see what is going on.

Alright, I did a simple test to put this to bed. I put a plain music CD in a drive I have that has no top cover so I can fully see the laser (connected via IDE to USB) - it's a useful drive I have around for other purposes. Anyway, then I fired up some emulators, MagicEngine and Ootake, booted with the System Card 3, and within ONE second, the Audio CD Player menu had booted showing you all available tracks on the CD, ready to play 'em, etc. The laser never really moved from the inner-most center of the CD to the outer-most, it stayed right there at the beginning of the CD... So, simply put, that tells me that the BIOS read the TOC, looped through all tracks, detected them as all of type 'audio' and acted accordingly. The laser didn't seek from the start to the end of the CD as you have suggested, looking for the first sector that is of type data as the first course of action. Again, that info is all right in the TOC, so why would you first blindly seek-scan the whole disc ??? Don't get lost in BIOS assembly, just think intuitively about it...

I tried another test with Ys IV as well. I burned a test disc where I removed track 2 from the CUE file, so the whole disc was all audio, except for the final data track. So within a second, the laser flew from left to right, all the way to the end of the disc and started booting the game, etc. Booting took ~3 seconds once it was there.

What I don't know is how seeking works exactly though, is it efficient or blindly linear, like if you ask the laser to seek to a LBA that is at the end of the CD or wherever, does it predict/compute a distance to move so it can be done quickly, possibly over/under-shooting in the process and then read the sector's Q subcode data and move accordingly (recovering), OR, does it read every sector's Q subcode data from start to finish until it finally gets to that sector that was asked for, etc. Cause if it's completely linear, then your suggestion about seeking the first sector that is of type data makes sense - It'll work and you wouldn't have to know the exact LBA in this case.

But anyhow, the relevancy of the 2 tests is that it clearly knows *in advance* from the TOC whether all tracks are of type 'audio' (in which case it boots the CD player menu) OR if there is at least one data track to try to boot from, etc. Conclusion: It scans the TOC first, as is normal and intuitive. As for how it seeks that data track, once it knows from the TOC that there is at least one, you could be correct about not using the LBA. It doesn't sound intuitive to me, but the technique you're describing based on the code could work. Perhaps it's a faster comparison in the seeking process, detecting a data sector versus the 4-byte comparison of the LBA. Not sure the easiest or fastest way to detect a data sector over an audio one, though. SectorHeader[15] would equal 01, indicating a mode 1 sector, but that means reading the sector data (which would slow things down), so rather, there'd have to be further flagging in the Q subcode data that's read in seek operations and that'd require less comparison op-codes for detection, etc.

[OldMan]

Yellowbook is an extension to Redbook that was created in 1985

Was going by dates in the ecma doc you posted. "High-Sierra" was 85, iso-9660 was 86, and yellowbook was 87. Not that there is that much difference, I suspect.
I did however mis-remember the sys 2.0 bios date. I thought it said 86, but in fact it says 89.
Given that it had to take time to develope and finalize everything, I could see them using high-sierra format for cds. It takes a while for production to catch up to the standards. So there could be minor differences, not that it matters.

Again, that info is all right in the TOC, so why would you first blindly seek-scan the whole disc ??? Don't get lost in BIOS assembly, just think intuitively about it...

Personally, I would use the TOC as well. But who know what the guys at NEC were thinking. I do wonder what exactly they thought of the ramifications of Section 20 in iso-10149 and emca-130. If you unravel the description, you will find that a cd isn't required to have a TOC - the lead-in area can be pure audio. Maybe they were thinking of how to deal with that.
[As an aside, I wonder what bozo left that hole in, and if there are actually any cds that -don't- have a TOC. I've never seen one, personally]

So, simply put, that tells me that the BIOS read the TOC

Probably. It may be doing the Q channel check on TOC data. I just don't see that in the bios code.
But then, I haven't unraveled it all yet, either

What I don't know is how seeking works exactly though, is it efficient or blindly linear,

I don't understand seeks that well either. I suspect that a seek is a high-speed read, where only the timestamps and channel codes are decoded.

Not sure the easiest or fastest way to detect a data sector over an audio one, though.

All you would need to do is monitor the Q channel bit. When it changes, you've hit a data sector. The Q bit is also encoded in the data stream, so it would be simple to check - at the hardware level. Maybe not so easy in packetized software, where you get a whole 2352 bytes at once.

After writing that, I opted to check it on my tg16. The 'seek' button is faster than playing, about 10 to 1. But that would still be too slow for the kind of performance we're looking at. However, the 'next track' button is awfully fast.
So maybe there is a faster speed for that operation. Even if we assume it goes directly to a particular track on the disc, the hardware still has to recognize that track, probably by watching the P channel bit. In theory, that same operation could apply to the Q channel bit, for recognizing a data track.

In theory, of course...

Back to the original question, though. The P bit has something to do with detecting the beginning and end of a track. I suspect that's why you can stuff extra audio in the 'gap' between 2 audio tracks - there is no way to check to make sure the data written is actually a 'gap'  (Audio tracks are pure data.)
The Q bit is used to recognize a data track - and that's probably how newer audio-only players mute those tracks (and refuse to play them) So if you are trying to get the actual start/end of the tracks you would need to check those bits yourself, instead of trying to calculate where the tracks start/end by the TOC times.
[And, from a programming point of view, if you get a 2352 byte sector back with the channel codes, it should be easy to switch between handling an audio sector (Q=0) and a data sector (Q=1).]

The problem with calculating start/end based on time is that the gap times given in all the documents are minimum times. The gaps can be longer, and that's perfectly acceptable. Iirc, one of the early us cds had the data track aligned to a second boundary - which meant it's gap was 00:03:01. That's right, 1 extra frame there. Drove me nuts for a while... (Fighting Street, I think it was)

As for not replying, don't sweat it. I've been busy myself trying to debug this demo for ccag. That's why I haven't started testing all this stuff. Or finishing the bios disassembly. Or any of the million other things I need to do. Reply when you get a chance.
And I'll probably hear from arkhan about spending an hour replying to this, instead of bug-squashing

[TurboXray]

Was going by dates in the ecma doc you posted. "High-Sierra" was 85, iso-9660 was 86, and yellowbook was 87. Not that there is that much difference, I suspect.
I did however mis-remember the sys 2.0 bios date. I thought it said 86, but in fact it says 89.
Given that it had to take time to develope and finalize everything, I could see them using high-sierra format for cds. It takes a while for production to catch up to the standards. So there could be minor differences, not that it matters

Not sure what doc that is, but yeah.. yellow book format was defined before ISO-9660. ISO-9660 was developed because of a need for a standardize file system for the data CDs, hence CDFS was born. That, and it standardized how the data and audio disc should be laid out for a CDFS setup (one data track, the first, followed by audio tracks). I'm pretty sure the boot identity string at the certain sector address wasn't originally in the ISO-9660 spec, but I could be wrong on that.

Again, that info is all right in the TOC, so why would you first blindly seek-scan the whole disc ??? Don't get lost in BIOS assembly, just think intuitively about it...

I doubt the sys card disassembly is going to get you much. It's at least one layer above the CD hardware. There's an embedded MCU (z80 based) with embedded ram that controls and interfaces with the CD (sony, last I checked) ICs. The 6280 communicates with this MCU device (hence the SCSI CD extension type command structure).

 On a side note, the data in the sector on the disc isn't exactly stored in linear format (though I think that's already known here), even though it's accessed as such. It's interleaved with other bits on the disc. For subchannel data on the TGCD (which is how it can play CD-Gs), you can get access to all of it per data sector - but it's given in something like 91 interrupts that are spaced out as the sector is being read (as opposed to just accessing it in linear fashion like you do with reading the data port for the sector data).

 BTW, love this discussion

[NightWolve]

Was going by dates in the ecma doc you posted. "High-Sierra" was 85, iso-9660 was 86, and yellowbook was 87. Not that there is that much difference, I suspect.

Not sure what doc that is, but yeah.. yellow book format was defined before ISO-9660.

I suspect he read this part from the ECMA-130 PDF I posted earlier: "The specification of the disk itself was contained in a document called "Yellow Book" issued by the Philips and Sony Companies for their licensees only. In Spring 1987 ECMA was asked to produce a standard reflecting the contents of the "Yellow Book" as the necessary complement to Standard ECMA-119", and from that, I guess concluded that Yellow Book was of 1987. But a proper inference is that it was already privately available to licensees-only (one or more years prior to 1987, '85 as stated), just that ECMA was asked to produce a standard based on it in the Spring of 1987, etc. They don't specify when, but glad to see they're not spreading the 1988 error.

I doubt the sys card disassembly is going to get you much. It's at least one layer above the CD hardware. There's an embedded MCU (z80 based) with embedded ram that controls and interfaces with the CD (sony, last I checked) ICs. The 6280 communicates with this MCU device (hence the SCSI CD extension type command structure).

Yeah, wouldn't be surprised. A visual test in this case was simple enough to make a sound conclusion. If the NEC CD system is basically a hacked audio CD player (David Shadoff's description), and the very first thing that a regular audio CD player traditionally does is load the TOC, well, I wouldn't expect dissimilar behavior here. Plus, I wasn't ready to fully trust someone's random BIOS level tracing of primitive Assembly. ;)

On a side note, the data in the sector on the disc isn't exactly stored in linear format (though I think that's already known here), even though it's accessed as such. It's interleaved with other bits on the disc.

Yeah, I just needed a way to describe two possible seek methods. Must you read the Q data sector by sector (linear) when seeking, or, can you compute some distance in advance based on the LBA to save some time and move the laser faster without reading every sector's Q data in between (since the physical characteristics of a CD are pretty fixed, a 120 mm round disc), etc. If that makes sense.

BTW, love this discussion

Kind of an awkward tangent in relation to the topic, but my main original interest was seeing how to solve the problem with pressing plants rejecting our mixed-mode CDs, trying to fully get to the bottom of what the problem really is and all that, etc. I figured someone would've complained at our detour here, actually, not the opposite. ;) (So nobody has the original Yellowbook... )

The problem with calculating start/end based on time is that the gap times given in all the documents are minimum times. The gaps can be longer, and that's perfectly acceptable. Iirc, one of the early us cds had the data track aligned to a second boundary - which meant it's gap was 00:03:01. That's right, 1 extra frame there. Drove me nuts for a while... (Fighting Street, I think it was)

Aha! Quite a coincidence! I had just discovered there was something unusual about Fighting Street a few weeks ago. I wanted an original disc to test with, and it just happened to be the one that I pulled out of my collection. I was worried that for such games, you'd have to force an even 3:00 pre-gap regardless of what was actually there which appears to be what CDRWIN and other software had been doing all along. I'll have to recheck that, but I just don't remember ever seeing a CUE file with an uneven time for the gap command, it's always been an even 2:00 or 3:00 seconds!

Below, I traced TurboRip in VC++2005 with the newly (WIP) Q subcode detection code and I marked the LBA values when index 01 changes to index 00, along with track number changes etc. I found that the first pre-gap is actually 230 sectors in length (not 225 like it should be!), so in MM:SS:FF format, it comes out to 03:05! Not a big deal mind you, just that it's unusual! It does present the small problem mentioned though, would I want to hard-code a rule, an exception, just for that game, despite what is actually being read/detected ?? I think not. It's no big deal to preserve it and burn it back exactly the way that it is.

// ** Fighting Street (U) transition layout **
   // Track 1, Index 01 = 0000 to 3364 (Actual Audio)

   // Track 2, Index 00 = 3365 to 3444 (Marked as Audio)
   // Track 2, Index 00 = 3445 to 3594 (Marked as Data)  [3594-3365+1 = 230 sectors of pre-gap]
   // Track 2, Index 01 = 3595 to 11330 (Actual Data)

   // Track 3, Index 00 = 11331 to     (Marked as Audio)
      // errors at 11336
      // 11337 continues
   // Track 3, Index 01 = 11481 (Actual Audio)

Probably hear from arkhan about spending an hour replying to this, instead of bug-squashing

S'alright, it's in the name of science!

[OldMan]

I suspect he read this part from the ECMA-130 PDF I posted earlier...

Yep. The only one I really remember, though, was the High-sierra, which definately pre-dated them all.
And the only reason I remember that is because there were other odd-ball formats up until then - and high sierra format wasn't embraced as a 'standard' back then (There was a lot of chatter about 'big' companies trying to force a standard through, and making everyone pay for it).

the very first thing that a regular audio CD player traditionally does is load the TOC, well, I wouldn't expect dissimilar behavior here.

I wouldn't expect it either. I just can't prove it. It's equally possible that having the scsi port connected alters the behavior of the CD drive. But I can't prove that one either.
Tom: Is there a RAM chip on the cd drive? If not, how would it store the TOC?

Below, I traced TurboRip in VC++2005 with the newly (WIP) Q subcode detection code and I marked the LBA values when index 01 changes to index 00, along with track number changes etc.

Cool. So (forgive my asking for this) Is there any way to correlate both the P and q channel changes with the index number changes, and see how accurate they are in relation to the TOC data? It might be possible that a change in the P and/or Q bit signifies the 'real' end of a track. (I still haven't figured out what the P bit actually indicates... )
Someday I'm hoping we figure this all out, and get something that can tell us exactly where things start and end on the cds. Not because I want a perfect copy, but because I want to be able to rip -just- the inter-track stuff and see what's in those gaps...

(I know, I can do it by hand, but that's a pain. Would be nice to rip just the gaps from various cds, and see how they align with each other. That could be part of reconstructing the original dev-kit code....)

From that dump, I have to laugh. the '1 sec' audio gap before the data is actually 79 sectors. Gotta love that; within the standard, but not anything a casual tinkerer would notice without looking for it.
But it does illustrate how important those channel bits are to getting a cd to pass testing for meeting the standards. Maybe someday I'll try embedding extra stuff in the gaps and see if I can get it to pass.
.......................................................
Quick aside: Does anyone know if you can combine audio, data and CD+G information on a CD? I can't see any reason you couldn't, but thought I'd ask first.

[Bt Garner]

-  "Made in Canada" was added to the case back

The original had this too because the original CD-Rs were actually made in Canada.  These were made in Indiana, which, as far as I know, has not been annexed by Canada.

[NecroPhile]

The original had this too because the original CD-Rs were actually made in Canada.

Original Version Signature Edition New Version

(another difference: the new one is missing the hyphen in "In-Game")

These were made in Indiana, which, as far as I know, has not been annexed by Canada.

Wishful thinking by Hoosiers that want to be Hosers?

[FiftyQuid]

These were made in Indiana, which, as far as I know, has not been annexed by Canada.

Not yet.   I'm sure you guys wouldn't miss it.

Got mine today.  It's crazy how the postal service (USPS and Canada Post) can be so slow sometimes.  I'll have something shipped to me and sometimes it'll take 2 days.  Other times I'm waiting weeks and weeks.  This shipment fell into the latter category.  Anyway, both games arrived today and both are in good condition;

/93.png

Thank you!