Jump to content

cubanismo

Members
  • Content Count

    163
  • Joined

  • Last visited

Community Reputation

137 Excellent

About cubanismo

Profile Information

  • Gender
    Male
  • Location
    California

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Just a note; prior art for using the LM1881 to extract vsync from composite sync when building a VGA cable... for an Apple II: http://www.apple2faq.com/knowledgebase/15khz-compatible-monitors/ Also lists a few compatible monitors.
  2. Indeed, and also recommended in the Retro Gaming Cables article I also linked in post #5, though for converting composite video -> composite sync. I should have read my own research more closely the first time 🙂 AFAICT (which isn't very far), the vsync extraction circuit it has is just a much better/more general version of the integrator + gate in the image above with some stuff in front to filter out the actual video values from the composite video wave to get composite sync from composite video first. My only concern with it was it appears the levels of the sync in composite video are much lower (~2v?) so it might get confused if you feed it 5v composite sync directly on the composite video input. I'm hoping a quick and dirty test with the integrator into an XOR gate will yield results since I should have the parts on hand, but if it works, I'll probably order some of the L1881 chips to try those out too. One thing I'm wondering is whether the Jaguar ever sends different video signals/timings out. For example, when using the high-res interlaced image display code out there, does it send a real 480i interlaced signal, or is the code just faking it over 240p somehow? I'm wondering if that would have any effect on how the sync extraction works.
  3. After a long email chain with my EE neighbor and much time on the bay, I'm proud to say I have an old Agilent Infiniium 54832D hooked up to this circuit, and it's now pretty clear why it's not working. During the main part/active region of the frame, the XOR circuit is pretty successful at canceling out the HSync pulses from composite sync. It still ends up with an edge in there that could be causing problems if monitors use edge trigger to detect VSync, but I'd have to revisit that later if the main issue below can be resolved. The main problem is that around the beginning and end of VSync, composite sync goes all funny and starts sending half-length HSync pulses at twice the line rate, then inverts to generate the VSync pulse, continuing to send these half-length HSync pulses at twice the usual rate, then inverts again to end the VSync pulse, and repeats the whole thing again as a sort of lead-out into the normal HSync pulses. The end result is that the "filtered" VSync generated by the circuit ZeroSquare suggested doesn't really look much cleaner than the original composite sync signal anywhere near VSync. Of course, this is all outlined in the HDRetroVision article I linked above in post #5, and looking at that article again to verify it matches what I'm seeing on the scope, I found it even included a sample circuit to extract VSync from composite sync: Should be easy enough to find the resistors and capacitors to try this out using the XOR gate IC as a comparator, but if i can't find them lying around, I might have to wait until my next digikey order.
  4. I don't suppose this ever happened? If not, I'd love to take a stab at this myself if you have the old source sitting around.
  5. From Urban Dictionary: I don't personally mind that much since these forums are pretty low-traffic and most of the threads aren't exactly what I'd call "important", but I do keep reading through these old "great deals on Jag games!" threads, getting all excited, then looking at the date and cursing under my breath.
  6. Yes, and the cinepak repacker is responsible for calculating SCLK automatically, as well as an audio drift value the DSP code uses to calculate when it should drop or replay samples (I think it only drops them actually, so I suppose the packer must always round the SCLK value down/clock rate up) to account for disparities. However, I can't find any code that actually makes the assumption the audio is 22.050k or 22k sample rate in the IMA DSP code, nor any relevant modifications in the 68k harness/player code, so I thought maybe there was some assumption in the avi_ima_encode.exe program. Are the IMA prediction tables and/or coefficients just tuned for ~22KHz, for example? If so, it probably doesn't really matter whether I'm using 22000Hz or 22050Hz. My mistake, my mind confused G.711 and G.722 after mixing beer and Wikipedia. Thanks for digging up the link. The decoder there does look like a match, and it even includes trivial source for an encoder, so I think I have everything I need to integrate it into some new tools. Now I just need to figure out what's going wrong on the transition from PCM->ADPCM in the merged DSP code. The interrupts seem to be a red herring: Something just goes wrong near the very end of my PCM track. Fiddling with the interrupts seems to perturb it, but doesn't seem to be the root of it. Needs more debugging.
  7. Not directly, no. I'm talking about the DSP routines @Orion_'s CinePak player module contains. See here: And just below where @CyranoJ moves to incorporate it into raptor 🙂 Orion claims authorship for this code, though he claims @Zerosquare helped him out with the encoder tool, and mu-law does seem to be one of the bajillion variants of ADPCM encoding, so it's entirely possible they're the same format. That said, this code uses the term IMA all over the place, and IMA is a different variant of ADPCM than mu-law from my reading.
  8. I was worried about something like that. Can this affect bank switching as well? E.g., can an interrupt come in just as I'm switching register banks and revert back to the prioir bank while clearing the interrupt? If so, that would imply I can only safely bank switch from an interrupt handler, which would be unfortunate.
  9. One other question I forgot to include: @Orion_'s docs say the decoder expects 22KHz audio input: Is that 22000Hz or 22050Hz? I've been using the latter and it seems OK, but I don't know what I'd be seeing/hearing if it wasn't. Audio/Video de-sync? An underrun eventually?
  10. Now that the basic cinepak stuff seems to be working well for me, I decided I wanted to encode a disk of music videos (One can only watch November Rain on Vid Grid so many times). 8-bit mono sound sucks for music, so I started looking at @Orion_ and @Zerosquare's IMA audio enhancements. I wanted to use the regular stand-alone cpkdemo cinepak player though, so I looked at what it would take to use the new dspcode with that app. That was too easy: You just copy Orion_'s dspcode.s file over and it works as-is. I figured it'd be cooler if you could mix IMA and raw PCM files on the same disk or use the same player code with the skunk to play both types of disks, so I looked into what it'd take to merge the two together. That was harder, and more to my liking. Attached is a dspcode.s you can drop into the existing cpkdemo player source and it will auto-select the right codec if you make one small modification to your IMA movies: Set the Audio Descriptor "Audio Compression Type" field to "2". Right now I'm doing this with a hex editor after running my files through JagCinePak, but I'll update my cinefix tool to take care of it shortly for those that don't want to get intimately familiar with the various Cinepak file formats. Now some questions for the audience: -Anyone know what variant of ADPCM IMA encoding avi_ima_encode.exe uses/this decoding code expects? ffmpeg lists 14, 2 of which (adpcm_ima_qt, adpcm_ima_wav) it can encode. I started trying to compare the ffmpeg decoders with the DSP code, but figured I could just ask first. I'm still working on my command-line cinepak conversion tool, and I'd like to pull as many parts of the process into this one tool as possible to simplify things. -I've had this playing in a loop alternating between a PCM and IMA music video for a while, and it's relatively robust, but sometimes it crashes at the start of a video. I'd like to chalk it up to Jaguar CD players being Jaguar CD players, but it seems less reliable at transitioning than the pure-PCM code. It used to almost always crash when switching modes, but I tweaked the init code (The stuff just after DSP_ENTR) a bit to not assume interrupts are disabled to get it to this point, so I feel like I'm still missing a detail there to get it to 100%. I did try disabling interrupts entirely for this portion of the code and it's been going strong like that so far, but the old PCM-only code doesn't need to, so it seems like it should be able to work with them enabled. Could it be the old code is racy somehow and the fact that I added a ton of instructions here just exacerbates an existing issue? I don't like using a fix I don't understand. -Totally unrelated, but while testing the auto-detection, I had to hack the audio descriptor in the 68k code to set the right bits for ADPCM files (I just hard coded a list of ADPCM tracks matching the content on my test CD). At first, when I had the bit in a different location, I was trying to do this with the following code: ; AUDIO_DESC is a long word in the DSP's memory ; Set bit 8 in that long word using a byte-sized bset-on-memory op on the 68k: bset.b #0,AUDIO_DESC+2 But this wasn't doing what I expected. I tried to verify it by reading it back as the full long-word on the 68k even: move.l AUDIO_DESC,d0 btst.l #8,d0 beq .skipprint move.l #IS_ADPCM_TXT,a0 ; Gymnastics to fix up MEMCON1 for Skunk w/CD unit went here bsr skunkCONSOLEWRITE Nothing, the bit wasn't set, and the DSP code concurred. Strangely, IIRC, this DID work: ori.b #1,AUDIO_DESC+2 Am I tripping over some weird alignment requirements or something here? Not a big deal as I don't even need this code anymore, but I couldn't figure out what was going on, so it bothers me. dspcode.s
  11. Any interest in a small patch to accept ":" as a command separator in addition to ";"? I've run into this as well. I also wish I could specify paths using the env variable and the command line and have rmac use the union of the two, kind of like you can do with spec files and "-I" in gcc. Any opposition to that? I could work up a patch.
  12. It's awesome seeing everyone's setups on here. Keep em' coming! I didn't used to think my old man reflexes could tell the difference between flat screen TV latencies and CRT, but now that I have a CRT again for the first time in years, it's just unbearable to do any serious gaming on the flat screen. I don't mind the upscaling artifacts as much as the latency.
  13. Yes of course. What's mine is mine and all that. However, I and others also have a right to an opinion that certain personal choices are rude. I personally feel the same about of print books that aren't in the public domain. Some people like to get on here and other places of discussion and vent about frustration over that behavior they feel is rude. They also have a right to do that, even to the point of being rude themselves. Making a reproduction can reasonably be viewed as political protest in this context: They are so upset by the simplistic unconditional rights endowed on creators by current copyright law that they knowingly break those laws, though of course now I'm mixing law and mortality up, which is always a mess. My point being, I don't think people's moral rights when it comes to intangible things like copyright are anywhere near as cut and dry as the prevailing law or the above comment implies. We all want creators to be encouraged, respected, properly compensated, and to control how their creations are used to some debatable degree, but does anyone anywhere get a warm fuzzy feeling watching those stupid "PIRACY IS THEFT!" infomercials the MPAA forces on us from time to time? To say creators have zero motal obligation and responsibility for their creations is just as naive as requiring them to produce more of them IMHO. I tried to thread the needle with a situation-specific interpretation in my prior comment in this thread, but @Zerosquare's response made me question it immediately. Context does matter. It's nice to have simple hard rules, but if things like this were actually that simple, we would have declared law bug free in the iron age or something and replaced judges with Z80s long ago. I realize this post itself is on a fine line between video game discussion and politics, and I went back and self-edited it a few times to remove political references as much as possible. Sorry if it's over the line mods. Do your thing if needed.
  14. Just wanted to post a helpful note on this thread about the EEPROMs (The save-game flash, not the big chips with the read-only game data). There's lot's of info out there noting you should use the 93c46/93c66/93c86 chips as appropriate for the game you're building, but it is rarely noted (Found some references in the Rebooteroids public beta thread and a few other buried references) that there are two (Well, three. I'll get to this.) variants of all these chips: one with 8-bit and the other with 16-bit data organization. Jaguar expects the flash organized as 16-bit words, as noted here: https://www.mulle-kybernetik.com/jagdox/cartridge.html. Look at the datasheet before you buy, and be sure you're getting the right memory organization variant. You can also get these chips in a variant that can support either mode depending on the value of an "Org" pin on the chip (Pin 6 on the 8-pin DIP Jag carts use), and this pin is floating on the Jaguar cartridge PCBs, so if you have one of these, just short pin 6 to pin 8 (VCC) to select 16-bit mode (Be sure that's the right value for your particular chip of course). On the chips I bought, pin 7 was also a write-protect bit, and had to be shorted to VCC as well to enable writes at all, as this pin also floats on the Jaguar cartridge PCBs. I just laid a bit of the capacitor leads that I snipped off after soldering those across all 3 of these pins and soldered it down to accomplish this. As usual, one of @Matthias's tools is a huge help here: If you have the right EEPROM and have it configured correctly, his EEPROM browser should auto-detect it and be able to manipulate the data on it. If you made a mistake somewhere, it won't report that the chip type was "detected", and/or you won't be able to manipulate the data. Of course, this only works if you have a BJL'd Jaguar, which everyone but me and a few other crazies thinks is heresy these days 🙂 Not a huge deal, but gave me quite a scare initially when I went to build some of those unpopulated fancy black PCBs from eBay after only recycling scrap cartridges from B&C in prior builds, which already had EEPROMs and capacitors on them, and wasn't getting any data saved!
  15. If you want to see some code that parses chunky & smooth cinepak files, look at my cinefix script above. If you're extracting cinepak from a cinepak-only disk using the cpkdemo player everyone has used, it'll have a bunch of AIFF and track header junk on it. Just scan forward from the start of the file until you find the 64-byte sync header of ASCII 1's, and then start reading the film/frame header structure. Again, see the cinefix code that re-wraps the cinepak file in these headers for details. If it's some other source (e.g., Battlemorph) you'd have to eyeball the tracks/files in a hex editor first to see if any of the extra padding is present. Quicktime .mov is a moderately more complicated container to write out than the Jaguar smooth/chunky files, but it probably wouldn't be too hard to add code to dump a .mov back out using the sample iterator and header parsing classes in cinefix. Converting to/from each container type should be a lossless operation (sample rate of the sound might be slightly perturbed at worst), so it'd end up no worse than your already-cinepak-encoded source material.
×
×
  • Create New...