ChanServ changed the topic of ##yamahasynths to: Channel dedicated to questions and discussion of Yamaha FM Synthesizer internals and corresponding REing. Discussion of synthesis methods similar to the Yamaha line of chips, Sound Blasters + clones, PCM chips like RF5C68, and CD theory of operation are also on-topic. Channel logs: https://freenode.irclog.whitequark.org/~h~yamahasynths
<andlabs>
did someone here talk about laserdisc preservation?
<cr1901_modern>
andlabs: /join #domesday86
<kode54>
a digital recording of an analog signal
<andlabs>
because I just bought a sealed one for reasons unknown and would like to get started at some point in the future, especially if I ever start buyign Mega LDs
<andlabs>
I am trying to figure out if that even is the case
<andlabs>
it's still pits and lands and it's still quantized
<andlabs>
it's not digital video, that's an entirely different thing
<l_oliveira>
laserdiscs are weird, in the sense they record digitally an analog signal
<kode54>
I know
<kode54>
it's a digital representation of an NTSC video signal
<kode54>
or PAL?
<andlabs>
actually I might as well throw in the Mega PC (LD Engine?) discs as well
<l_oliveira>
or pal yes
<cr1901_modern>
digital? I thought laserdisc was pure analog
<andlabs>
even though there are only like four of them
<andlabs>
lol
<kode54>
pits and lands can only be digital
<l_oliveira>
LD ROM I think is the name for PC Engine LDs
<andlabs>
lol
<l_oliveira>
MEGA LD for SEGA discs
<andlabs>
that's totally not unambiguous
<andlabs>
I wonder if it's as technically idiotic as PCE CD
<l_oliveira>
the most bizarre thing about MEGA LDs is that they're not region locked
<cr1901_modern>
kode54: Are you sure? I thought a laserdisc would work like a record player in that respect
<kode54>
hmm
<cr1901_modern>
groove depth would represent the value
<l_oliveira>
but SEGA CDs and MEGA CDs are
<cr1901_modern>
which is continuous
<kode54>
in that case, I don't know
<andlabs>
on a CD, the pits and lands do not encode data
<andlabs>
it's the transition between the two that does
<andlabs>
(or the lack of a transition)
<l_oliveira>
it's their transitions, right?
<l_oliveira>
the encoding is what? EFM?
<andlabs>
if Laserdisc works the same way, then what cr1901_modern just said won't work
<l_oliveira>
ah laserdisc encoding is different from CD
<cr1901_modern>
Yes, at least that's my understanding
<l_oliveira>
it ends generating an analog signal but not using an DAC
<kode54>
a PWM?
<andlabs>
it is PWM
<andlabs>
that much I know
<l_oliveira>
only really late models had DACs on it
<cr1901_modern>
laserdisc is fairly analogous to using a laser to read the signal encoded on vinyl?
<kode54>
in which case you can have a digitally quantifiable signal
<andlabs>
I hgihly doubt the DACs fo 1978 would have produced aceptable vidoe quality
<l_oliveira>
because when it was invented there were no DACs fast enough to output megahertz of stream
<cr1901_modern>
If the signal is analog why would you need a DAC?
<cr1901_modern>
>only really late models had DACs on it
<l_oliveira>
late models had things like frame buffers for pause mode
<kode54>
figure it's similar to DSD
<andlabs>
by 1978 digital audio recording was still measured at most 10 or maybe 12 bits of precision
<kode54>
high MHz low precision signal
<andlabs>
and even then with one or two exceptions they were all either classical or experimental jazz
<cr1901_modern>
DSD?
<kode54>
when lowpass filtered, results in a proper analog signal
<l_oliveira>
a early LD when you pause it keeps skipping around the same frames it has on the very same disc revolution
<kode54>
DSD is what SACD uses for audio
<l_oliveira>
so it keeps blinking
<kode54>
2.8 MHz 1 bit digital signal
<andlabs>
and EVEN THEN EVEN THEN unless you were recording with Denon or Sony your original digital masters are now unreadable
<andlabs>
because the very brief 3M digital recoders were extremely unstable and no one has the schematics anymore
<l_oliveira>
late units would likely use a DAC instead to be able to fill the still buffer with a frame
<l_oliveira>
digitally
<andlabs>
so yeah, forget a DAC in 1978
<cr1901_modern>
Do you mean ADC?
<l_oliveira>
laseractive has a buffer in it for still
<l_oliveira>
DAC not ADC it is outputting not acquiring
<cr1901_modern>
But how did the analog signal become digital in the first place :P?
<l_oliveira>
it never become analog
<andlabs>
the noise floor of compact cassettes are roughly equivalent to that of 6-bit PCM
<l_oliveira>
the old player extracts the video from disc differently
<andlabs>
I highly doubt video signals would have survived at all
<cr1901_modern>
But I'm pretty sure Laserdisc isn't digital!
<cr1901_modern>
so you start with an analog signal in the first place
<l_oliveira>
the new one would output video using the same method a CD use
<l_oliveira>
the old players do work like you said
<l_oliveira>
new ones with much faster chips can extract data digitally
<andlabs>
I think cr1901_modern is asking about how the discs were made, not how the players work
<l_oliveira>
oh, I see
<andlabs>
alternatively, how the recorders work
<cr1901_modern>
So there's an ADC to capture data from the disk on new players
<l_oliveira>
there were several different formats of writable laserdiscs, no?
<andlabs>
not in the consumer market
<cr1901_modern>
and yes, I'm focusing on the disks themselves. Apparently it's FM formatted
<andlabs>
that being said I still need to find out how to preserve CDs
<cr1901_modern>
but the continuous version of FM, not the digital version
<l_oliveira>
there were no writable laser discs in consumer market at all
<andlabs>
and also how to preserve PCBs
<andlabs>
and maybe also how to preserve ASICs depending on what technology they use
<cr1901_modern>
Guess I should ask domesday86 to point me to literature on how they work
<andlabs>
IDK if it's ULA, PLA, PLD, CPLD, or what
<l_oliveira>
asics are rotting lol
<andlabs>
yes, that's why
<l_oliveira>
how you gonna prevent that from happening ?
<andlabs>
and I'm referring to the Sega CD model 1's
<cr1901_modern>
Amazing the Sonic 3 prototype survived intact
<andlabs>
that's not an ASIC, that's a ROM
<l_oliveira>
roms rot too
<andlabs>
I don't know if it's a mask ROM or a PROM
<andlabs>
but those are more reliable
<andlabs>
either way
<l_oliveira>
and roms rotting are more common than asics
<andlabs>
huh
<andlabs>
ok
<andlabs>
technolgoy how does it work
<l_oliveira>
prototypes likely are on eprom
<l_oliveira>
not mask
<l_oliveira>
maskrom are like asics for practical comparation
<l_oliveira>
just the layout are different
<andlabs>
but yeah I know of an ASIC that is apparently dying en masse now apparently????
<andlabs>
so it needs preservation
<andlabs>
but also this is just hearsay
<andlabs>
and also I still don't know how to preserve PCBs
<andlabs>
X-rays?
<andlabs>
I thought byuu figured this out for their SNES game preservation stuff but apparently they didn't?
<superctr>
it's hard to preserve an ASIC, best you can do is take a photograph
<superctr>
and hope the circuit can be reversed from that alone (a la furrtek's neogeo stuff)
<superctr>
in some _very_ rare occurences the original schematics have been archived and released
<whitequark>
you could use ptychographic tomography for ASICs
<l_oliveira>
andlabs, I suspect the asics dying is due to poisoning from the encasing plastic releasing ions on the metallization layer and bounding wires
<cr1901_modern>
Is that what ppl used to get pictures of Core i7 layers (I may be misremembering)?
<l_oliveira>
Particularly bad with Fujitsu and Ricoh I think
<l_oliveira>
Fujitsu rot affects Konami boards particularly bad
<andlabs>
yay plastic cases
<andlabs>
which reminds me
<l_oliveira>
Ricoh rot affects CPS1 and 2 and SNES consoles are dying outright as well from that
<andlabs>
what's with that thin gold stripe on ceramic cases?
<l_oliveira>
marking the pin1?
<andlabs>
no, it's a lateral stripe
<superctr>
isn't some sega pcbs also almost exclusively fujitsu and ricoh
<andlabs>
goes from edge to center, not a pin
<l_oliveira>
ya SEGA has tons of Fujitsu parts on them yes
<superctr>
and namco also
<andlabs>
but it seems ot be universal
<l_oliveira>
Toshiba stuff seems to be stable
<superctr>
but i suppose hitachi and toshiba parts also aren't invincible
<l_oliveira>
Hitachi too
<superctr>
for now maybe
<superctr>
we'll see in 20 years
<l_oliveira>
yeah
<superctr>
also, i suppose ricoh is the reason why old SNES consoles are dying also?
<l_oliveira>
So I think one of the misery foundry vendors Yamaha used and are still unidentified was Seiko Epson
<superctr>
of course there's maybe not as urgent need to preserve those
<superctr>
i think epson should be recognizable
<superctr>
afaik their packages are distinct
<l_oliveira>
I found a 16KB SRAM from Epson which looked exactly like one of the YM2612 packages
<cr1901_modern>
SuperFX was fabbed by Sharp. How long before those die?
<l_oliveira>
most chips are epson indeed
<l_oliveira>
some nec on the other side of the board
<l_oliveira>
two I think
<l_oliveira>
the cpu and the other one near by
<superctr>
the ones that are nec branded of course
<superctr>
i'm thinking of the hudson marked ones
<superctr>
those are all epson i think
<cr1901_modern>
whitequark: I can't find the paper I'm looking for, but there was a team that extract metal layers from a recent Intel CPU using tomography, correct?
<superctr>
there are even two smaller epson marked ones (memory i suppose)
<linkmauve>
Any of you at 36c3 btw?
<superctr>
can the average hardware collector preserve asics using tomography
<superctr>
if not thn i think there's little hope to preserve everything
<cr1901_modern>
superctr: You can't preserve everything
<l_oliveira>
there is another chip which has the sound hardware
<superctr>
and yes i already know the answer :P
<l_oliveira>
I think it's C6230 or something like that
<l_oliveira>
it is the same size as the C6270s
<cr1901_modern>
Even if we could, ej5 discussed another nasty gotcha a few months ago- some fabs "lose the recipe", where environmental conditions required to make an ASIC were lost over time.
<superctr>
it might be hidden
<superctr>
unfortuantely evan amos forgot to take a picture from straight above
<l_oliveira>
it's just the sound part of the original C6280 chip with ADPCM units also built in
<superctr>
maybe it's a split duty, at least it does the DMA part
<l_oliveira>
it has a ton of ram
<l_oliveira>
that's two 512KB EDO RAM chips
<l_oliveira>
near it
<superctr>
yeah it seems to be a DMA controller
<l_oliveira>
it does pump the ADPCM data
<l_oliveira>
probably pushes it on the C6230
<superctr>
yeah
<superctr>
adpcm volume is a '30 register
<superctr>
anyway
<superctr>
<cr1901_modern> Even if we could, ej5 discussed another nasty gotcha a few months ago- some fabs "lose the recipe", where environmental conditions required to make an ASIC were lost over time. <- when it comes to replacing asics, i think that you need to find an electrically compatible fpga or similar (using breakout boards where required) that can be programmed
<superctr>
it is not economical to roll out new ASICs, unfortunately
<superctr>
it's especially an issue with old boards that use 5V logic
<superctr>
but even finding a big enough fpga that is 3.3v might be an issue in the future
<superctr>
it's really not, for the reasons i just mentioned
<superctr>
you will need a breakout board with logic converters, at least
<cr1901_modern>
fun fact: That painting was considered completely unremarkable unti;l it was vandalized
<superctr>
and then it's questionable how accurate the timing will be, it'll of course depend on what fpga is used, but considering how widespread the 6502 was it's hard to know exactly how compatible it will be
<superctr>
when recreating an entire system in fpga, the timing and voltage stuff becomes much less of an issue, but at that point you can basically make a chip out of fanfiction rather than actually preserving the original logic
<superctr>
that is when it starts getting dangerous (like that painting)
<l_oliveira>
ctr, that's how people started calling FPGA reimplementations emulators
<l_oliveira>
lol
<cr1901_modern>
Please do not open that can of worms here, I beg you
<cr1901_modern>
That conversation never ends well
<l_oliveira>
I think that painting explains it well
<l_oliveira>
and it sort of gives the defenders of "fpga is emulation" a lot of ammo
<superctr>
yeah, we don't have to talk about FPGA implementations
<superctr>
i'm talking about preserving ASICs
<l_oliveira>
well of course
<l_oliveira>
to preserve them you need to destroy some to actually document and archive
<superctr>
and i think preserving them is to actually reverse-engineer and recreate the original logic, rather than assuming what it is
<cr1901_modern>
"Once upon a time, Nintendo contracted a bunch of engineers at Ricoh to create an ASIC. The engineers created a spec- if only an ad-hoc one- of how the chip should behave and left all other behavior unspecified. >>
<l_oliveira>
assumptions is how we got at the point people are having these weird discussions
<superctr>
throw enough software developers at it and they'll figure out how to use every single undocumented behavior
<superctr>
that the hardware engineers didn't even think of
<cr1901_modern>
When this ASIC was released, the programmers were curious about this chip. They played with it and used the chip in ways the engineers never intended in order to make their code go fast. >>
<l_oliveira>
that's one of the reasons SONY never gave anyone low level specs for the PS2 console (only NAMCO I think had access to the PS2 at very low level due to them using it on arcade games)
<l_oliveira>
devs only had a software specification and APIs to interact with
<cr1901_modern>
30 years later, all the Ricoh engineers moved on. In fact, they were probably sick of this Nintendo ASIC project by the time it ended! They have no idea what assumptions they encoded into their design anymore. The design documents are prob long gone! >>
<cr1901_modern>
And now chips are dying faster than REs can learn _all_ the assumptions _all_ the software devs completely broke when using this chip in the 90s! >>
<cr1901_modern>
What I'm saying is- you can never go back (tm) :'D!"
<cr1901_modern>
The end
<cr1901_modern>
whitequark: tyvm
<whitequark>
you can definitely go back with high throughput ASIC RE tools
<cr1901_modern>
Okay, those last few lines are an exaggeration.
<whitequark>
we just need to make those
<superctr>
you can take some shortcuts
<whitequark>
netlist extraction should be a 1 day task, not a 1 year task
<superctr>
all ASICs using standard cell designs
<superctr>
like the fujitsu ones that furrtek discovered
<l_oliveira>
neogeo and CPS2 use plenty of those
<cr1901_modern>
There do exist some ASIC RE tools that can match to a set of cells you specify. Nothing cheap tho.
<superctr>
extracting a schematic from those are a lot easier than having to figure out everything manually (though you might still miss a few layers that need to be routed manually)
<l_oliveira>
probably the same ones Konami use from Fuji, too
<cr1901_modern>
>netlist extraction should be a 1 day task, not a 1 year task
<cr1901_modern>
I agree. And re: the exaggeration- SNES RE has done a wonderful job preserving the console. But not sure how much that approach scales.
<l_oliveira>
amazing that ricoh asics are dying more often now than fujitsu
<superctr>
apparently they were unreliable even in the 90s
<l_oliveira>
not that bad really
<superctr>
many SNES consoles that broke due to bad ASICs
<l_oliveira>
I worked repairing game consoles
<superctr>
but well, that might just be amplified due to mass production
<cr1901_modern>
could be memoryless and or bathtub distribution of "time to failure"
<l_oliveira>
and while I replaced S-CPUs eventually
<l_oliveira>
it was not as bad as how it is now
<l_oliveira>
I still have my super famicom, the original PPU1 on it failed in a way mode7 became useless
<cr1901_modern>
l_oliveira: Would you be willing to take video if possible? I like watching failure modes of video ASICs :P
<l_oliveira>
that was 15+ years ago I no longer have the faulty chip
<l_oliveira>
it was repaired quite fast as I can replace these myself
<l_oliveira>
I'll try to find the post at gamesx forums
<cr1901_modern>
it's like Mode 7 gave up more than half the time
<l_oliveira>
try playing mario kart on such a system
<superctr>
it probably makes drunk mario kart even more fun
<cr1901_modern>
although I thought mode7 only allowed one BG (or two BGs but not invididually scrollable)
<l_oliveira>
you can't see the obstacles but they're there
<cr1901_modern>
and this picture shows 2 (the land and the water)
<superctr>
i think it's one BG but the pattern generator gets incorrect coordinates
<l_oliveira>
there's games that use a plane on top and other on the bottom with different pixel patterns
<l_oliveira>
I think they just can't overlap?
<superctr>
you can clearly see it's wrapping
<superctr>
in mode 7, the CPU sets the coordinates and affine transformation matrix every scanline
<l_oliveira>
probably because the metalization of the chip failed
<l_oliveira>
these writes were arriving wrong at the chip
<l_oliveira>
I have a C6270 chip with a detached pin
<cr1901_modern>
>these writes were arriving wrong at the chip how do you know?
<l_oliveira>
the chip just became open without any reason
<l_oliveira>
think of some FM synth running, in the middle of music playing you disconnect say D3 between it and the CPU
<l_oliveira>
what you think will happen?
<cr1901_modern>
Well everything goes to hell
<l_oliveira>
it will keep playing but the notes will deform horribly
<l_oliveira>
now if what happened only affected a few specific registers?
<cr1901_modern>
what I'm asking is: what if the write bus to the PPU's VRAM is intact (as well as the R/W interface _to_ the PPU is intact), but the _read_ bus when reading from VRAM was fucked?
<cr1901_modern>
Couldn't that also be plausible (I doubt the chip has internal bidir buses)
<superctr>
if so then it shouldn't only affect mode 7 i think
<superctr>
cpu doesn't really need to read anything from vram for mode 7
<cr1901_modern>
? where's the mode 7 data stored then?
<cr1901_modern>
(I know from kevtris' work that color RAM is internal to the chip)
<superctr>
all the things the cpu needs is in rom, lookup tables etc
<superctr>
as for the ppu, mode 7 works like any other video mode
<cr1901_modern>
mode 7's format for storing data is a bit different from the other modes, where you store your tile data first, then you store pointers to the tile data, and then you store metadata about pallete and the offset into the pointers to begin.
<cr1901_modern>
(IIRC)
<cr1901_modern>
And I don't remember how it works
<superctr>
right
<superctr>
so mode7 is 256-colors
<superctr>
so the palette is a bit different
<cr1901_modern>
But in all cases, the PPU is reading from that VRAM
<superctr>
PPU is always reading from vram though, in all modes
<cr1901_modern>
to figure out what to do next
<cr1901_modern>
>(8:37:12 PM) superctr: in mode 7, the CPU sets the coordinates and affine transformation matrix every scanline
<cr1901_modern>
Oh, whoops
<cr1901_modern>
parse fail
<cr1901_modern>
Misread as PPU
<l_oliveira>
there's some special interconnect between the ppu1 and ppu2
<l_oliveira>
that fails often too
<l_oliveira>
you get weird faults like only the outlines of sprites appear
<cr1901_modern>
somewhere in my logs, I have the format of the data that goes down those connections
<l_oliveira>
or sprites without BGs
<l_oliveira>
things like that
<l_oliveira>
I usually pop out PPU1 for that and test the ESD diodes on the PPU1 chip
<l_oliveira>
if any ESD diode fails I assume the pin is detached and replace it, so far never had a mis detection
<l_oliveira>
I had bad PPU1s which failed internally, no pins were detached
<superctr>
can nintendo's test rom detect this?
<l_oliveira>
the case of missing BGs or sprites, no it can't
<l_oliveira>
will pass all tests
<l_oliveira>
I don't remember but I think the mode7 one also passed all tests
<l_oliveira>
well, the kind of videochip these PPUs are you can't exactly see what is being output to the video as a still frame, right?
<l_oliveira>
from the CPU side I mean
<cr1901_modern>
Right I have a stalled project to RE that test ROM out of sheer curiosity lol
<l_oliveira>
SEGA's MD test program also got leaked
<l_oliveira>
a fairly late one which support six button controllers
<l_oliveira>
from circa 1992
<cr1901_modern>
do you have a ROM of that?
<l_oliveira>
of course
<cr1901_modern>
that you're willing to share?
<l_oliveira>
I made a cart out of it
<cr1901_modern>
ahh
<l_oliveira>
certainly
<l_oliveira>
I got it from AG
<l_oliveira>
I think AG is gone now?
<cr1901_modern>
Supposedly the owner ran out of funds
<cr1901_modern>
I don't remember what happened anymore, but someone I know in emudev got royally screwed over by him, so I never felt compelled to stick around. >>
<cr1901_modern>
But since I can't even remember the context anymore, maybe I should drop it
<l_oliveira>
only emulator that passes I/O check is Charles MacDonald's
<cr1901_modern>
Not even BlastEm or Exodus?
<l_oliveira>
well circa the time I got the rom
<cr1901_modern>
ahh
<l_oliveira>
Exodus is based on Mac's emu, no?
<l_oliveira>
I do think Exodus will work
<cr1901_modern>
I have no idea
<l_oliveira>
that test doesn't do anything horribly fancy, it just plays Space Harrier2 music and show some colors after testing the system and the device connected to the controller port
<l_oliveira>
it works with mouse and other kinds of controllers too
<cr1901_modern>
how does it detect it? IIRC the Genesis controller port is a very naive protocol
<cr1901_modern>
how does the Genesis* detect a mouse*?
<l_oliveira>
MSX can use a mouse
<l_oliveira>
and have a similar controller port
<superctr>
genesis controller port is just basic PIO interface
<l_oliveira>
the 4bits of the directional inputs are used to transfer the coordinates values from the dislocation
<superctr>
you can set any pin to input or output
<superctr>
and enable pullups on input pins (?)
<l_oliveira>
it has a serial mode too but that's a different thing
<cr1901_modern>
yea, but... 4 bits of resolution doesn't seem to be enough for a mouse :P
<l_oliveira>
no pullups are always on
<superctr>
the serial mode is used for a modem, but it's so slow it's pointless to use it for anything else
<cr1901_modern>
I thought Genesis had a db9 on the back for a modem?
<l_oliveira>
that's a third controller port
<superctr>
the expansion port works exactly the same as the controller ports
<superctr>
the gender is reversed though, for some reason
<cr1901_modern>
is the edge connector another expansion port?
<superctr>
maybe to prevent people from plugging in controllers
<l_oliveira>
to prevent people from connecting the controller there
<l_oliveira>
the edge connector is a cartridge slot
<superctr>
edge connector is for mega cd, it's more like a cartridge port
<superctr>
i think it has a few more pins though
<cr1901_modern>
ahhh, because the edge connector is what I think of when I think of "expansion port"
<l_oliveira>
each cartridge slot is assigned a 4MB memory window
<l_oliveira>
when a signal on the top cart slot is pulled low they swap around
<l_oliveira>
that's how it knows a cart is inserted
<l_oliveira>
when no cart is inserted the side slot is actually mapped at 0x0
<l_oliveira>
and that's how the CD unit boots when no cart is plugged
<l_oliveira>
the SEGA-CD BIOS actually look for a CD header at the cart slot, if it finds one it boots the cart as if it were a CD lol
<l_oliveira>
exactly how the SATURN boots cartridges
<superctr>
there's a "sense" pin on the cartridge slot
<superctr>
cd cartridges were supposed to just omit that
<superctr>
so the bios would boot instead
<superctr>
the backup cartridge works like that also
<l_oliveira>
They only had that idea on the US BIOS
<l_oliveira>
the Japanese MEGA-CD BIOS does not look up for a bootable cart
<l_oliveira>
the very first MEGA-CD BIOS does not block a US SEGA GENESIS from running
<superctr>
i think the only megacd cartridge released (flux) actually doesn't use the bios to boot it anyway
<l_oliveira>
meaning it will work on any console, no pesky "THIS MEGA CD UNIT WILL ONLY OPERATE AT BLABLABLAH"
<l_oliveira>
Pier Solar controls the CD exactly the same way FLUX did
<superctr>
pier solar is unlicensed, so i don't count it as a release, even though technically it is
<superctr>
also released many years after sega stopped supporting it
<l_oliveira>
what it does is look for the CD BIOS, find the packed stub with the sub CPU BIOS, unpack it on the sub CPU work area and tell the sub CPU to run
<superctr>
you could just load your own sub cpu bios if you wanted
<superctr>
especially if you don't plan to use the cd drive at all
<l_oliveira>
to do that one has to reverse-engineer the CD BIOS to copy the ASIC init process and how to unpack the sub CPU BIOS
<superctr>
if you just want the soundchip and extra memory, i think it could be viable
<l_oliveira>
the soundchip is a sub cpu peripheral and that's very lame
<l_oliveira>
because you have to start it and use it to access the sound chip
<cr1901_modern>
is that not what Pier Solar does?
<superctr>
i don't think starting the subcpu is very complicated
<superctr>
the extra memory would be worth it anyway
<l_oliveira>
it uses the drive to play CD DA music
<superctr>
alone
<l_oliveira>
you can't use the sub cpu ram with the main cpu if the sub cpu is running
<cr1901_modern>
and that's accessible without the main cpu?
<cr1901_modern>
err sub* cpu
<superctr>
yeah you can
<superctr>
subcpu has two ram areas
<l_oliveira>
if the sub cpu is stopped
<l_oliveira>
you can use the sub cpu ram
<l_oliveira>
oh no that's different
<l_oliveira>
that's the word ram
* cr1901_modern
is having deja vu to this exact topic around the exact same time last year
<l_oliveira>
it's for dma transfers with both cpus running
<superctr>
you have 256kb of wordram, and then 512kb of subcpu exclusive ram
<l_oliveira>
the sub cpu has 512KB of EDORAM
<superctr>
the thing is that subcpu can also access the ricoh chip while it is playing samples
<superctr>
so you can use all of that for nice quality samples
<superctr>
and swap samples while playing music (like sonic cd does)
<l_oliveira>
the word RAM is a pair of 64KB chips you can swap around or set them as a single bank of memory
<l_oliveira>
you can set them anyway you want without having to stop the sub cpu
<superctr>
if you want better sound quality than snes with your cartridge game, this is viable i think
<superctr>
only catch is that you need a megacd...
<l_oliveira>
the idea with wordram is that you can have one page set on the subcpu and other on main, they can flip around seamlessly and that favors dma transfers like full motion video
<l_oliveira>
or a painfully long load cycle
<l_oliveira>
SEGA had this idea of developing a expansion RAM cartridge for the system
<superctr>
it's a pair of 1 megabit banks though, not 64kb
<l_oliveira>
it never materialized
<superctr>
so 256kb in total
<l_oliveira>
64Kword
<l_oliveira>
64K 16bit
<l_oliveira>
my bad I should have said word
<superctr>
i think you can use all of wordram for scratchpad on 68k side if you don't use the asic capabilities
<superctr>
or even to transfer data quickly between subcpu and main if you use it in split mode
<cr1901_modern>
Oh that's right... I wanted a dead Sega CD so I could extract the RF5C68 from it
<cr1901_modern>
need to get around to doing that this century
<l_oliveira>
5C164
<l_oliveira>
not 5C68
<cr1901_modern>
same difference
<superctr>
but yeah, the subcpu exclusive ram is basically useless for anything except samples :P
<l_oliveira>
they're physically different
<superctr>
so you can consider the megacd to have 512+64kb of sample memory :P
<superctr>
almost anyway
<l_oliveira>
different pinout
<superctr>
need to store data also
<cr1901_modern>
well, I want _some_ sort of ricoh sample chip to mlount to a breakout board
<cr1901_modern>
and it's not like I can find them on ebay
<cr1901_modern>
it wasn't a popular chip
<l_oliveira>
I did and it didn't work
<cr1901_modern>
(afaict)
<l_oliveira>
I suspect my chip was fubar
<l_oliveira>
got two more to try
<l_oliveira>
recently
<superctr>
fm towns uses a similar chip also (i guess it's '68 though)
<cr1901_modern>
where'd you get them?
<l_oliveira>
it is a 68
<cr1901_modern>
from dead boards or an aution site?
<cr1901_modern>
auction*
<l_oliveira>
from dead boards
<l_oliveira>
that's why I think my chip was fubar
<l_oliveira>
RF5C68 and akin should work fine on Z80 based systems
<superctr>
btw l_oliveira the "Mega CD hardware manuals" has all the ASIC registers, and i think it contains all info needed to initialize a megacd as long as you don't use the cd drive
<l_oliveira>
I was having a weird problem where my chip could not access properly the RAM connected to it
<cr1901_modern>
"Mega CD hardware manuals" without CD drive init? That sounds weird
<l_oliveira>
ctr, it says nothing about setting up the sub cpu
<superctr>
couldn't zoom it out enough to screenshot all pages
<superctr>
but you can probably find it yourself in the pdf
<l_oliveira>
the point of saying that interacting with that directly is prohibited is that if they developed a new version of the machine, they could change from sanyo to other vendor and have the BIOS handle that difference
<superctr>
yeah, that is true
<superctr>
that is why they just had cartridge games copy the sub bios from the IPL ROM anyway
<superctr>
but a homebrew developer doesn't need to do any of that shit :P
<superctr>
sega isn't making any more funny revisions of the megacd
<cr1901_modern>
>that is why they just had cartridge games copy the sub bios from the IPL ROM anyway
<cr1901_modern>
Can you elaborate?
<cr1901_modern>
I thought Sega CD games were, well, CD media
<superctr>
<l_oliveira> what it does is look for the CD BIOS, find the packed stub with the sub CPU BIOS, unpack it on the sub CPU work area and tell the sub CPU to run
<l_oliveira>
CD BIOS = IPL ROM
<l_oliveira>
sub CPU BIOS is packed at the end of the IPL ROM
<l_oliveira>
nemesis algorithm if I remember well
<cr1901_modern>
Oh, this is for carts that wanted to use the Sega CD hardware
<l_oliveira>
yes
<l_oliveira>
you need the sub cpu to command the cd drive as the registers which deal with it are connected to the sub cpu not main
<superctr>
and the sub cpu doesn't boot without the intervention of the megadrive 68k
<l_oliveira>
when you copy the sub cpu bios on the sub cpu ram and kick it off the first thing it does is init the lights (green and red)
<l_oliveira>
then it starts the drive and tries to load TOC
<l_oliveira>
the MD 68k actually loads up the program the CD 68k will execute on the CD 68k RAM
<l_oliveira>
there is no ROM on the CD 68K only RAM
<superctr>
just like the z80 on the MD itself
<cr1901_modern>
So where is the BIOS chip? I assume it's on the MegaCD PCB?
<superctr>
the BIOS chip is IPL ROM on the megacd itself
<superctr>
it's the "cartridge" the megadrive 68k boots instead of the actual cartridge
<superctr>
it contains the splash screen animations etc
<superctr>
but most importantly the subcpu BIOS which is copied to ram
<l_oliveira>
the sub cpu is kind of modular
<cr1901_modern>
So when you say "that is why they just had cartridge games copy the sub bios from the IPL ROM anyway" >>
<l_oliveira>
it has the bios and a user program
<cr1901_modern>
you're referring to Genesis carts in theory using the SegaCD hardware?
<superctr>
yeah
<l_oliveira>
when the splash screen animation is running it had a user program loaded which uses the ricoh chip to play the opening screen music
<superctr>
but there was only one cartridge (and later one homebrew release) that worked this way, flux
<l_oliveira>
and do the control of the sprite resizing hardware which rotates and scales the mega-cd logo
<cr1901_modern>
the homebrew release being pier solar?
<cr1901_modern>
or another game?
<superctr>
yeah
<superctr>
pier solar
<cr1901_modern>
never heard of flux
<superctr>
32x games do something funny to allow the megacd to boot normally, so the 32X can be initialized later
<cr1901_modern>
I was under the impression that _no_ licensed Genesis game ever used the SegaCD hardware
<l_oliveira>
I don't think 32X games can init the CD, can they?
<cr1901_modern>
and thus it was at best a curiosity