It is currently Sat Oct 21, 2017 5:24 am

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 83 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next
Author Message
PostPosted: Thu Mar 10, 2016 4:49 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 530
ADPCM just means standard XA-ADPCM as used on thousands of PSX discs (and it's nothing undocumented, it's quite similar to SNES BBR btw.). If you know the File/Channel and MM:SS:FF values where specific PSX games have their ADPCM stuff stored, then you could play that audio via the "ADPCM" test function. Many PSX games are also using normal uncompressed CD-DA Audio tracks, so that could have been expected to have happened in SNES games, too.

Going by the datasheet, the REGADR is 5bit wide, bit4 is don't care for the "Xnh" registers. Some of the "Xnh" registers are referring to the "current sector" (that from most recent DECINT interrupt), and there can't possibly be TWO different "current sectors", so bit4 is really not selecting anything in that cases.

The six buttons and LCD panel are probably only for playing Audio discs without TV set connected, which would be a rather unlikely/unimportant scenario for a SNES emulator. Games might be able to completely disable that stuff via the mechacon "Key Ignore" commands (assuming the command is related to the buttons).

The new APU might make sense if it has more extras, like PSX-style stuff with 24-channel audio or better echo, then it would have been worth the effort to put a new APU in expansion units (though such features might require more Sound RAM to be of any real use).

The missing extra CPU power could have been solved by just using a BIOS cart with coprocessor (as done by various SNES game carts), so that could have been implemented without problems without needing to change the CDROM drive hardware. Even with the fastest coprocessors, the main bottleneck would have been squeezing possible highest-quality graphics through the SNES PPU hardware.

---

And, even with my fifteen year old PC, I've defeated all those photo sharing sites for multimedia quadcore smartphone generation artists... studied all the hardware photos at their creative viewing angles and their insanely low and insanely high resolutions... wondered how often the photographers have stumbled over their own feet... and, anyways, here's my first guess on the component list:
Code:
Sony Playstation SFX-100 Console - Component List
 Mainboard
  IC101 100pin Nintendo S-CPU, 5A22-01  (65816 CPU with joypad I/O ports)
  IC102 100pin Nintendo S-PPU1, 5C77-01 (Video Chip 1)
  IC103 100pin Nintendo S-PPU2, 5C78-01 (Video Chip 2)
  IC104 28pin  NEC uPD43256A6U-10L? (32Kx8 SRAM, Video RAM 1)
  IC105 28pin  NEC uPD43256A6U-10L? (32Kx8 SRAM, Video RAM 2)
  IC106        ... whatever, maybe S-ENC
  IC107 64pin  Nintendo S-WRAM (128Kx8 DRAM with B-bus)
  IC108 28pin  65256BLFP-12T   (32Kx8 SRAM, Sound RAM 1)
  IC109 18pin  Nintendo F411   (NTSC CIC)
  IC110 28pin  65256BLFP-12T   (32Kx8 SRAM, Sound RAM 2)
  IC111 64pin  SONY CXP1100Q-1 (APU, some newer S-SMP revision, SPC700 CPU)
  IC112 80pin  SONY CXD1222Q-1 (APU, some newer S-DSP revision, Sound Chip)
  IC113 20pin  LC78815M        (Two-channel 16bit D/A converter 1)
  IC201 80pin  SONY CXD2500AQ  (CDROM Signal Processor)
  IC202 20pin  LC78815M?       (Two-channel 16bit D/A converter 2)
  IC203 48pin  Noname   ...  maybe Servo Amplifier (like CXA1782BR on PSX?)
  IC204 80pin  SONY CXD1800Q    (CDROM Decoder/FIFO, equivalent to CXD1196AR)
  IC205 18pin  74xxxx? (PCB has 20pin solderpoints, but chip is only 18pin)
  IC206 28pin  SONY CXK58257AM-70L (32Kx8 SRAM, CDROM Sector Buffer)
  IC301 8pin   Texas Instruments RC4558, "R4558 TI 25" (Dual Op-Amp 1)
  IC302 ...    ... whatever, maybe one of the 8pin IC???'s
  IC303 8pin   Texas Instruments RC4558, "R4558 TI 25" (Dual Op-Amp 2)
  ICxxx ...    if any... ?
  IC??? 8pin   whatever (front board edge, near headphone socket)
  IC??? 8pin   whatever (front board edge, near headphone socket)
  IC??? 24pin  whatever (front/mid board edge) (probably S-ENC or so)
  CN201 29pin  To LCD Board
  CN..  ..     To CDROM Drive
  CN..  ..     To Controller Ports
  CN..  62pin  SNES Cartridge Slot
  CN..  ..     Rear panel
 Daughterboard with LCD
  IC701  80pin NEC uPD75P308GF  (CDROM Mechacon?)
  IC7xx ...    if any... ?
  X701         oscillator
  CN701  28pin LCD and six Buttons    (28pin, or maybe 2x28 pins?)
  CN702   4pin to somewhere  (2 LEDs ?, left of drive tray)
  CN703  29pin to Mainboard           (29pin, or maybe 2x29 pins?)
  CN704   3pin to front panel (disc eject button?, right of drive tray)
  ICxxx ...    if any... ?
  N/A?  28pin  Something like BA6297AFP,BA6398FP,BA6397FP,AN8732SB,etc ?
 Daughterboard with controller ports
  ???   ...    whatever
 Daughterboard with Eject button
  ???   ...    whatever, a button, and maybe more stuff for the 3pin wire
 Daughterboard with LEDs
  ???   ...    whatever, two LEDs, and maybe more stuff for the 4pin wire
Components in actual CD Drive unit
  ???   ...    whatever
 External Connectors
  2x controller ports (front)
  1x headphone port with "level" regulator (front)
  1x "NEXT" port (serial link like PSX maybe?)
  1x Audio R        (red) (apparently with mono-switch when not connected)
  1x Audio L (MONO) (white)
  1x Video          (yellow)
  1x S VIDEO
  1x RF DC OUT
  1x MULTI OUT
  1x DC IN 7.6V

BIOS Cartridge - Case Sticker "'92.10.6." (plus some japanese symbols)
  PCB "RB-01, K-PE1-945-01"
  IC1  64pin  Nintendo S-WRAM (128Kx8 DRAM)
  IC2  64pin  Nintendo S-WRAM (128Kx8 DRAM)
  IC3  32pin  HN2xxxxxx? (Sticker 0.95 SX) (ROM/EPROM)
  IC4  28pin  SONY CXK5864BM-12LL (8Kx8 SRAM)
  IC5  16pin  Noname?
  IC6  14pin  74F32 (Quad 2-input OR gates)
  IC7  16pin  74F138? (1-of-8 inverting decoder/demultiplexer?)
  IC8  14pin  Noname?
  IC9  14pin  Noname?
  IC10 16pin  Noname?
  IC11 16pin  Nintendo D411 (NTSC CIC)
  ?    ?      white space (in upper left)
  ?    2pin   something with 2 pins is apparently on PCB back side (battery?)

Note: The date codes on the three S-WRAM's, D411, and uPD75P308GF seem to be
from 1991. Sticker on case of BIOS cart seems to be from 1992.


Last edited by nocash on Thu Mar 10, 2016 7:18 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Thu Mar 10, 2016 6:18 pm 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
To be fair, the CPU concern could have been offset simply by the fact that CDs allow more stuff, period. Not fighting to cram in everything into a relatively small ROM alone can do wonders, even if you still have to fight to keep a portion (e.g. a level) into RAM (and even that, consider how much it'd be allowed to take on a cartridge instead!). This seemed to be quite a common thing actually.

Also the PCE CD was like this too if I recall correctly (aside from the constant addition of more RAM over time). The Sega CD was the only one to add any significant improvements beyond CD audio (only to have it go to waste by promoting FMV instead, argh!).


Top
 Profile  
 
PostPosted: Thu Mar 10, 2016 6:48 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19113
Location: NE Indiana, USA (NTSC)
I seem to remember there were two proposed specifications for the SNES CD: the first just a CD drive (essentially a parallel to the FDS), and the second actually including a coprocessor of some sort. This unit may be the first type.


Top
 Profile  
 
PostPosted: Thu Mar 10, 2016 10:15 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1338
> The new APU might make sense if it has more extras, like PSX-style stuff with 24-channel audio or better echo, then it would have been worth the effort to put a new APU in expansion units (though such features might require more Sound RAM to be of any real use).

Anything's possible, but I really don't think this is at all likely.

They have the ADPCM and CD-DA playback, there's no reason for barely enhanced SMP audio. The device was intended to connect to the expansion port of the SNES, not be a new console. Hence why it's so weird that this prototype has it all merged together like this.

How do you know these are newer revisions of the SMP/APU chips, anyway? This is the first time we've ever seen these part numbers, aside from seeing D1222 on the decapped die scans of the S-DSP from I believe it was digshadow.

> The missing extra CPU power could have been solved by just using a BIOS cart with coprocessor

Yes, it certainly could have, but without the chip present (or even named), we can't emulate it. If we stick our own coprocessor onto that cart, it's joining the MSU1 in the pseudo-hardware realm.

You can easily stick the 32-bit ARMv3 (ST018) onto this cart or an MSU1 cart right now if you wanted in bsnes. You could overclock it to 700MHz, too. Doesn't really mean anything, though.

> Even with the fastest coprocessors, the main bottleneck would have been squeezing possible highest-quality graphics through the SNES PPU hardware.

To me, the Achilles Heel of this system is the miniscule RAM content. 256KiB with a 1X CD-ROM drive. This system would have had monstrous load delays like the FDS all of the time.

Developers would have had to upload the VRAM data into the cart RAM ($21ex registers can't DMA into VRAM, they're both on the B-bus), shunt that into VRAM, then load 256KiB of level data + programming code. Definitely doable, but it's tight. Der Langrisser has 700KiB of dialogue text alone, for instance. So you'd be loading new data for every single scenario and scene transition of the game.

What they really needed was at least four times the RAM. Or if they were truly and completely insane, and could afford 16x the RAM, they could have sold a service that allowed 95% of the library to be burned to new CDs in store kiosks ala Nintendo Power. But that would have definitely cost too much. Looks like 1MiB of SRAM went for $27+ in 1993 as per http://www.jcmit.com/memoryprice.htm

> studied all the hardware photos at their creative viewing angles and their insanely low and insanely high resolutions... wondered how often the photographers have stumbled over their own feet...

Hahah, yeah. Smart phones have made (really, truly terrible) photographers out of everyone.

If this were my system, I would have placed the PCBs on my flatbed CCD scanner and captured 1200DPI scans.

> To be fair, the CPU concern could have been offset simply by the fact that CDs allow more stuff, period.

The SNES will always be a CPU-bound system. It's truly horrendously slow. You hear 3.58MHz, but it takes ~4 clock cycles just to execute a single instruction. So you're already below 1MIPS. And now you have an ISA that has only one accumulator and two index registers. Even just adding a value without carry requires two instructions usually. So realistically, this is about equivalent to a 200KHz 8086 CPU ... if you took out the MUL/DIV instructions.

Yes, you can make SNES-class games. But I don't think there would have been a market for "SNES games, but with longer loading times. Also requires a $250 CD-ROM add-on."

All of the proposals from Sony and Phillips spoke of additional CPU horsepower, which could have helped with much more complex enemy AI, etc.


Top
 Profile  
 
PostPosted: Thu Mar 10, 2016 10:44 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19113
Location: NE Indiana, USA (NTSC)
byuu wrote:
The SNES will always be a CPU-bound system. It's truly horrendously slow. You hear 3.58MHz, but it takes ~4 clock cycles just to execute a single instruction.

And on a 68000, it takes even more cycles despite being clocked twice as fast.

Quote:
Even just adding a value without carry requires two instructions usually. So realistically, this is about equivalent to a 200KHz 8086 CPU ... if you took out the MUL/DIV instructions.

Wasn't the 8086 heavily multicycle too, like the Z80 and 68000? I seem to remember that it didn't reach one instruction per clock unti the i486 era.


Top
 Profile  
 
PostPosted: Thu Mar 10, 2016 11:51 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1338
> And on a 68000, it takes even more cycles despite being clocked twice as fast.

Sure, but we're talking about the SNES-CD, not an SNES vs Genesis debate again :P

I'll let you know my thoughts on that if I ever emulate the Genesis (odds are 1:10,000 at this point.)

> Wasn't the 8086 heavily multicycle too, like the Z80 and 68000? I seem to remember that it didn't reach one instruction per clock unti the i486 era.

Probably. Okay then, it's about equivalent to a 200,000 instructions per second 16-bit CPU that has a couple of arithmetic-capable registers. Or less if said CPU can multiply and divide natively.


Top
 Profile  
 
PostPosted: Fri Mar 11, 2016 2:20 am 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 788
Wikipedia seems to think the 8086 averaged about 15 cycles per instruction (from a source that seems to put the 486 around 1-1.4), compared with ~2.3 for the 6502 (from a source that puts the 8086 below 7) and nearly 3 for the i486DX (from a source that puts the 6502 at ~44). I haven't personally programmed any of those, but I imagine that when assessing the performance of an old CPU it matters rather a lot what exactly you're asking it to do...

Still, 200kIPS? Are you serious? I mean, it's no i7, but that's an average of nearly 18 (fast) cycles per instruction. How fancy is your hypothetical instruction set? Or are you thinking of what would happen if you tried to run C on it?

...

Considering how cheap CDs are/were, might it have been feasible to do a cart/disc combo game, with the game code on the cartridge handling the BIOS' duties? Lots of ROM, and the potential for an add-on chip to boost CPU power... It would have been more expensive than just a cartridge, but by how much?


Top
 Profile  
 
PostPosted: Fri Mar 11, 2016 6:15 am 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
byuu wrote:
Hence why it's so weird that this prototype has it all merged together like this.

Wouldn't be the first time this happens though. Could have been just a debug machine for all we know.

byuu wrote:
To me, the Achilles Heel of this system is the miniscule RAM content. 256KiB with a 1X CD-ROM drive. This system would have had monstrous load delays like the FDS all of the time.

256KB from the cartridge + 128KB from the SNES own RAM. This isn't really that different from the Sega CD setup, and that usually didn't do loading times during a level (only between them). Then again it seems the 5th gen didn't fare much better either despite more RAM and faster drives (and in many cases the biggest culprit of huge loading times were scratched discs =P).

byuu wrote:
Der Langrisser has 700KiB of dialogue text alone, for instance. So you'd be loading new data for every single scenario and scene transition of the game.

More likely, for each dungeon.

byuu wrote:
You hear 3.58MHz, but it takes ~4 clock cycles just to execute a single instruction.

I was under the impression it was 2~3? But I guess I'm just looking at the fastest instructions (which honestly should make the bulk of the code if it's optimized, but then again I wonder how much the lack of registers would get in the way)

byuu wrote:
Yes, you can make SNES-class games. But I don't think there would have been a market for "SNES games, but with longer loading times. Also requires a $250 CD-ROM add-on."

Would have probably gone the way of the Sega CD (read: straight ports with CD music and FMV games, ugh), although admittedly even that one had a more powerful CPU which helped with decompression, so maybe it'd have been closer to the PCE CD... OK now that doens't sound encouraging (for the PCE that was sorta useful especially after the RAM expansions, but for the SNES that doesn't sound very helpful)

That said, it's likely the SuperDisc may have been in response to the PCE CD, much like how the CD drive in the Sega CD was.


Top
 Profile  
 
PostPosted: Fri Mar 11, 2016 10:24 am 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1338
Looks like I'm stuck again >_>

It doesn't seem to matter what I return from the STS and HDR reads. It'll probably require more disassembly of the BIOS itself to understand what it's looking for.

> Wouldn't be the first time this happens though.

Wow, trippy :D

Well, perhaps that is indeed the case. But then, again, I don't think they'd customize the APU in a way that'd break BC with SNES games, and I don't think a final unit would exist in a form other than as an add-on unit. Could be wrong, but I doubt it.

> 256KB from the cartridge + 128KB from the SNES own RAM.

Sure, but SNES games need work RAM too. Any they use for program code is going to take away from work RAM.

> I was under the impression it was 2~3?

2 is the minimum, I think 7 is the maximum. 4 is a good average for eg lda $2137

> OK now that doens't sound encouraging

It really isn't. I think the SNES-CD would have flopped horribly had it been released. Nintendo has never pulled off expansion hardware well, and honestly, neither has Sega or anyone else (sans maybe PCE-CD in Japan only?) The thing that makes it so alluring is the fact that we never actually received it, and the SNES was so well revered.

It would have been damn expensive, without much of a jump in quality, and the games would have still sold for $50 a piece like the Mega CD did.

Now throw in another 6-12 months to get from Super Disc prototype to mass market, and you're less than 6-12 months away from the PS1's debut (obviously, that wouldn't have happened if the partnership didn't fall through, but still. The SNES hardware was already old hat in mid-'93.)


Top
 Profile  
 
PostPosted: Fri Mar 11, 2016 12:30 pm 
Offline
User avatar

Joined: Thu Jul 29, 2010 2:24 pm
Posts: 37
nocash wrote:
That isn't obfuscated. The bios test function displays all mechacon commands with friendly names, and outgoing hex values, and with expected response hex values in plain text on the TV set. You don't even need to dump the bios cartridge (and least to disassemble the program code) for understanding how port 21E1h is working.
Code:
  Access MM/SS/FF     BmmssffF                --> FFFFFFFF
  Access Track/Index  CttiiF                  --> FFFFFF
  Stop                D01F                    --> FFFF
  Play                D02F                    --> FFFF
  Pause               D03F                    --> FFFF
  Open/Close          D04F                    --> FFFF
  Fast Forward        D10F                    --> FFFF
  Fast Reverse        D11F                    --> FFFF
  Forward             D12F                    --> FFFF
  Reverse             D13F                    --> FFFF
  Key Direct          D40F                    --> FFFF
  Key Ignore          D41F                    --> FFFF
  Continous Play      D42F                    --> FFFF
  Auto Track Pause    D43F                    --> FFFF
  Auto Index Pause    D44F                    --> FFFF
  Normal Speed        D45F                    --> FFFF
  Double Speed        D46F                    --> FFFF
  Q-Data Request      D50F 0000000000000000F  --> FFFF ................F
  Status Request      D51F 01234F             --> FFFF .....F

Only problem are the variable response bits in the Q-Data and Status requests. 16-digit Q is probably 8 bytes straight from SubQ channel. And 5-digit status, well, that part might require disassembling the bios.

Add this as well. Press X after sending a command in the Communication menu.
Code:
  Restore             F                       --> F


EDIT:
So this wasn't really mentioned, but here's how $21E1 works:
Commands are sent nibble by nibble, and at every nibble sent, a nibble must be read. The lower 4-bits are used for this.
Let's take Stop command for exemple, which is D01F. The expected answer is FFFF.
Send 0x0D, Read 0x8F (0x80 = busy)
Send 0x00, Read 0x8F
Send 0x01, Read 0x8F
Send 0x0F, Read 0x8F

That's basically it. The default read without any command sent (like at boot) shouldn't even matter at all.
EDIT2: I only typed this for documentation purposes. Honestly I was pretty busy and I just got to understand this part.


Top
 Profile  
 
PostPosted: Mon Mar 14, 2016 1:54 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 530
Okay, got the thing emulated & documented. Booting from CDROM works fine, and even the Tray eject button is emulated as extra gimmick. Documentation should cover about everything, from component list, memory and I/O map, and volume/bootsector info and specs for the BIOS functions at 00h:Exxxh.

For the CDROM emulation part, I'll still need to add something that avoids problems with zerofilled SRAM (that makes the BIOS think that the checksum is good, and 0 files exist... and 0 bytes are free). And, I've a few other CDROM-unrelated details on my todo-list (like adding some final notes to the NSS and Nintendo power specs). I hope to get a no$sns update released next some days.

Anyways, before somebody else releases the first SNES CD game, here's one: http://problemkaputt.de/magicflr.htm (with binary and source code included). For the records: That is the first-ever SNES CD / Super Disc game released ever! The image is in burnable CUE/BIN format, although no$sns is simply ignoring the CUE file's content (supports only MODE1 .bin with 800h-byte sectors). Alternately, ISO will be also supported, allowing to use MODE1/MODE2 discs with 920h-byte 930h-byte sectors, that would also support ADPCM discs (haven't emulated ADPCM or CD-DA playback yet though).

Just for curiosity, here's the mechacon command log from no$sns TTY debug message window, recorded when booting the above game:
Code:
Mechacon: D51F01234F --> FFFF10B00F (Status Request)
Mechacon: D51F01234F --> FFFF10B00F (Status Request)
Mechacon: D01F --> FFFF (Stop)
Mechacon: D51F01234F --> FFFF10100F (Status Request)
Mechacon: D51F01234F --> FFFF10100F (Status Request)
Mechacon: D51F01234F --> FFFF10100F (Status Request)
Mechacon: D51F01234F --> FFFF10100F (Status Request)
Mechacon: D51F01234F --> FFFF10100F (Status Request)
Mechacon: B000216F --> FFFFFFFF (Access MM/SS/FF)
Mechacon: D02F --> FFFF (Play)
Mechacon: D51F01234F --> FFFF10200F (Status Request)
Mechacon: D03F --> FFFF (Pause)
Mechacon: B000200F --> FFFFFFFF (Access MM/SS/FF)
Mechacon: D02F --> FFFF (Play)
Mechacon: D51F01234F --> FFFF10200F (Status Request)
Mechacon: D03F --> FFFF (Pause)
Mechacon: B000217F --> FFFFFFFF (Access MM/SS/FF)
Mechacon: D02F --> FFFF (Play)
Mechacon: D51F01234F --> FFFF10200F (Status Request)
Mechacon: D51F01234F --> FFFF10200F (Status Request)
Mechacon: D03F --> FFFF (Pause)
Mechacon: D01F --> FFFF (Stop)


Last edited by nocash on Mon Mar 21, 2016 11:34 am, edited 2 times in total.

Top
 Profile  
 
PostPosted: Mon Mar 14, 2016 2:30 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 530
tepples wrote:
Yet the Sony design continues to show through, as VAG is BRR with a longer packet, different filter types, and a different Gaussian table.

The sound test seems to be using normal 9-byte BRR sample blocks. But I might have misunderstood that sentence, and don't really know what the "VAG" part was referring to. The cdrom sectors in XA-ADPCM format?

At the moment, I would assume the APU chips are just rebadged standard SNES chips. Unless they contain some completely different new stuff like address decoding for port 21E1h-21E4h, and producing whatever 21E4h is meant to do, and maybe also containing an UART for accessing the NEXT port (assuming that it's a PSX-style serial port).

It would be weird to handle that kind of features through the APU chips though, but there's no other chip discovered yet that could do those things. Unless that's done by IC203, but then the board wouldn't have a Servo Amplifier attached to the CXD2500AQ chip, so that won't work out, unless that ominous "CD-ROM control board" that TriMesh talked about does actually exist, then the Servo Amp might be located on that board. I assume that it might be some PCB on the bottom/rear of the drive-unit.

The only photos that I've seen are showing only the top/front sides of the drive - are there more drive-unit photos anywhere??? Oh, and are there photos of the six push buttons??? I've only seen fractions of the button/lcd panel yet, the upper-right button seems to be a "Remain" button, no idea if there's also a Play/Pause button or whatever.
EDIT: Found a picture showing LCD and buttons : http://www.retrogamenetwork.com/wp-cont ... cdtop1.png

byuu wrote:
and we have no idea what the 36-pin unmarked IC is on the board.

Uh, which 36pin chip on which board is that? I haven't found a photo showing any such chip or board yet.

LuigiBlood wrote:
Add this as well. Press X after sending a command in the Communication menu.
Code:
  Restore             F                       --> F

Send 0x0D, Read 0x8F (0x80 = busy)

Yup, I've spotted the "F" somewhere else, too. It's apparently intended to abort/flush command transfers (as they are all ending with an "F" digit), the response digit for "F" could be whatever garbage (if it's issued in the middle of get-status command). Btw. for some reason, the BIOS is somehow randomly sometimes issuing "Play-F-Play" instead of just "Play" when loading the volume descriptor (haven't figured out when/why it's doing that). Oh, and for all commands, the last response digit can be don't care (or some status value, the BIOS checks if lastnibble="B" after the MM/SS/FF seek command; with "B" meaning Bad or Busy or whatever).
Ah, and for 21E1h.bit7, that's the IRQ flag indicating ready (not busy). As far as I can tell, that flag must be automatically cleared after reading.


Last edited by nocash on Mon Mar 14, 2016 3:24 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Mon Mar 14, 2016 2:56 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19113
Location: NE Indiana, USA (NTSC)
nocash wrote:
tepples wrote:
Yet the Sony design continues to show through, as VAG is BRR with a longer packet, different filter types, and a different Gaussian table.

The sound test seems to be using normal 9-byte BRR sample blocks. But I might have misunderstood that sentence, and don't really know what the "VAG" part was referring to. The cdrom sectors in XA-ADPCM format?

VAG is the extension commonly used for files that hold PlayStation audio in 16-byte blocks (called SPU-ADPCM in psx-spx). Until I recently read psx-spx I wasn't aware of the similarities between XA and VAG. I mentioned the similarity between BRR and VAG (that is, SPU-ADPCM) as evidence that the S-DSP's Sony part number would likely have resembled that of the PS1 SPU.


Top
 Profile  
 
PostPosted: Mon Mar 14, 2016 4:01 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 530
Oh, didn't knew that VAG was a PSX file extension (I cared only about emulating the PSX hardware). Yes, SNES APU's BRR samples, and PSX SPU's VAG samples, and CDROM decoder's XA-ADPCM samples are all quite similar, with different block lengths, and different filters, and different interpolation.
Btw. can you make sense of the Zigzag interpolation http://problemkaputt.de/psx-spx.htm#cdr ... ompression used for CDROM XA-ADPCM sectors? It's producing more or less inaudible noise, and I can't image why they've being doing that. Is that some commonly used/useful interpolation technique, or is it a weird hardware glitch? A bit offtopic, but then, the SNES Super Disc's XA-ADPCM playback mode might be doing that, too.


Top
 Profile  
 
PostPosted: Mon Mar 14, 2016 4:02 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19113
Location: NE Indiana, USA (NTSC)
Zigzag is probably the sinc function multiplied by a tapering window or something very closely related, commonly used as an interpolating filter or low-pass filter.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 83 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group