Jump to content


New Members
  • Content Count

  • Joined

  • Last visited

Community Reputation

19 Good

About Kaide

  • Rank
    Star Raider
  1. That's what I figured. I just didn't want to assume.
  2. You can make one, but it doesn’t mean the NT Mini has any idea what to do when one is inserted. That bit of logic to load the correct core based on the adapter needs to be implemented, and do we have any idea if that is in the JB firmware? Sent from my iPhone using Tapatalk
  3. And as I pointed out, 8-bit CPUs/VDPs don't use 8-bit addressing, it's not enough. VDPs since they are more custom can be a little weird too. The NES' PPU uses 14-bits for addressing to cover both 2KB of VRAM and the CHR memory, even though it could have also used 16-bits like the CPU. More bits per pixel, a wider color palette, more color palettes to pick from, more sprites per scan line, and on screen. All those contribute to the leap in graphical fidelity. Beyond that, it's just a case of how you get there. You need more throughput to handle this, and a bigger VDP/PPU die. You can get more throughput by upping the clock speed, but will your VRAM keep up? Can you get stuff manufactured at tolerances good enough to run at the new clock speed? Or do you go wider and start using 16-bit data buses to move data more quickly? Moving towards 16-bit data buses makes a lot of sense there once you aren't pushing two data buses across the cartridge slot. NOTE: While looking at the better documented SNES schematics, I realize I may have made a mistake after realizing the DMA controller was embedded in the CPU. If the PC Engine CPU has a DMA controller, that is how the VRAM would have been bulk populated, very similar to the SNES. I mistakenly thought the DMA at this point in time wouldn't have been integrated into the CPU die. That's my mistake for assuming it was integrated as part of an SoC or more modern CPUs. TIL. Also interesting, the Commodore 64's VDP used a 12-bit data bus to read from Color RAM and VRAM at the same time and speed things up. Neat. I'm not sure, but that should have been "per process". PAE was supported in XP and later, so that should be able to address more than 4GB of RAM. And protected memory meant each app had its own address space, so there's no reason you can't allocate 6GB of RAM on a 32-bit CPU with PAE support across your processes. That said, Windows did some really goofy memory mapping in the day, and I never kept a close eye on things. I do remember the I/O mapping nonsense.
  4. It doesn't. There's no DMA access for the PCE VDP to the CPU's data bus. The VDP had some DMA functionality for bulk transfers within VRAM itself that would be faster than trying to move things around using the CPU, and would use DMA to access VRAM, but that was about it. And yes, it doesn't match a lot of VDP designs of 8-bit computers and other consoles. But it does mean that the VDP generally didn't have to fight the CPU for access to VRAM unless doing bulk loads. Just at the cost of time spent loading up VRAM with tile data. Also weird is that it stored tile data in a planar format, despite using color indexes. So each row of an 8x8 tile was 4 bytes, and you had to load all 4 bytes in order to know what color even one pixel was. A lot of the VDP design suggests that they went wide/parallel in their design in order to improve fill rate at lower clock speeds. Not that 16-bit itself actually made anything possible here. I'm totally confused by the "assuming it would even fit" comment. VDPs have always been limited in what they can access and the size of their sprite/tile table. The trick there has always been to load just what you need. Generally this would be what you need for a level or screen between opportunities to load new tile data. Or abusing palette swaps and duplicate tiles to compress the data. Also, I should point out that the 8-bit systems did use 16-bit addressing. It's how you got a 64K logical address space in the first place. Both the SNES and Genesis had 24-bit physical addressing. The 68k with a clean 24-bit logical address space was a nice CPU to work with (helps that it was designed with 32-bit in mind, so registers were 32-bit despite only having a 16-bit ALU), while the 5A22 used the DB register to form the top byte of the 24-bit addresses. That lead the SNES to have a rather nasty beast of a memory map to avoid having to modify the DB register too often. If anything the PC Engine, despite being limited to 16-bit logical addresses, had a much easier bank switching setup to work with to provide 21-bits of physical addressing. One that my old TI-83 mimics with it's Z80 chip. Honestly, 16-bit by itself isn't really a panacea. It does enable some things, yes. But a lot of the CPU designs of the era weren't pure 8-bit or 16-bit. They never really were, and couldn't afford to be with RAM needs outstripping the ability to address it (even with 32-bit, the desire to address >4GB hit long before 64-bit CPUs with 64-bit ALUs were a thing). It was however, a very clever bit of marketing to draw a more stark line between the consoles of the 80s and early 90s.
  5. I believe I have worked out what's going on here. I've got a couple rips I've made myself using cdrdao that work that I was having problems with before. So it looks like the MegaSD doesn't like 2048-byte sector rips. At least if you are including the audio tracks as part of a single bin file. When I finally got back to looking at this, I tried again using a raw rip and it works fine. Possibly a bug/assumption in the code that calculates the audio track offset relying on 2352-byte sectors, along with how it reads the region from the image. It's really weird though, since the data track still loads/runs fine and doesn't seem to introduce bugs by using 2048-byte sectors. It just seems to trip up the region detection and audio track playback. I've thrown together a simple shell script to make ripping my collection for the Mega SD less fiddly: CDRDAO SegaCD Rip Script for MegaSD on Mac This script should be easy to convert to Linux, I just haven't made the changes needed, but I've made comments in the script about what needs to be considered.
  6. Yeah, don't remind me of the delays I dealt with on the Mega SG. In my case they kept tripping over their own feet. 1 week to get an RMA, 2 weeks to get the replacement (because they screwed up the shipping on the replacement unit and required ground shipping for the return). Yeah, I nearly waited a month from the start of shipping (don't forget the 1 week shipping of the wrong unit too) to get the unit I ordered when I ordered on day 1 based on their previous track record with the Super NT launch. That's not a great feeling. And I have called out their incredibly similar packaging for the different SKUs wondering if that might be part of the problems they faced with a new shipping partner. I get your frustration here. I've been there. However, the way you are going after TerraOnion comes off as petty. Yes, sure, he moved. I don't really see how operating out of Andorra makes any difference, except in the context of getting bit by the speed of customs. This is really not the attack to make here, IMO. This comes across as one of those 20/20 hindsight issues where you lash out for the mistake, but at the same time, I would be surprised if anyone expected customs to be limited to 45 packages a day. If a single person handles all customs, that's still about 10 minutes/package for clearance. I honestly wouldn't have had it cross my mind that such a thing was possible in this day and age, even if dealing with a city state (which Andorra pretty much is). You are reading too much into what was said here. It's clear that it is in stock, but even if he hands it over to customs, that bottleneck is still going to delay it leaving the country and reaching DHL. Here's the thing. If you were complaining that he should make sure there's a notice on the website about customs delays so people can make an informed choice, that's one thing. If you were complaining that he's not willing to help make things right by eating shipping costs for the delayed packages, or offer refunds for any packages that can be reclaimed from the customs queue, that's still a valid argument. Attacking where someone chooses to live and arguing over the meaning of "in stock" over a customs problem (i.e. something that happens during shipping) comes across as incredibly petty, IMO.
  7. Ordered 6/19. "Shipped" 8/4. In DHL's System 8/8 (picked up in Andorra). Being a small business reliant on shipping honestly sucks. If you have retail space, you can multi-purpose that for inventory/etc. If you want to have prime access to shipping, you need to either buy/lease warehouse space and staff it, or hire someone to do it for you. Analogue has demonstrated that hiring someone who has warehouses to manage inventory/shipping is a mixed bag. And if you are boutique enough, neither makes a ton of sense because your inventory could fill a small room. I don't really have strong opinions either way about TerraOnion in particular, and I've obviously criticized their communication in this thread already (and think they could do better here as well). I do find it somewhat amusing that we've gotten so used to the advantages that owning warehouses or even whole shipping networks gives an online business that we are demanding it from small businesses where they don't operate on that kind of scale, and generally are niche enough that having to hand over 30-50% of the sales price to distributors/retailers can price the product out of the market. Probably a bit of both. DHL seems to be picking it up after the packages are cleared through customs (the bottleneck). I suspect these big shippers have customs agreements with many countries to help speed things along, that also aren't at play here because of the size of Andorra.
  8. This reads really poorly, TBH. It took me a few read-throughs to get at what you are really trying to say, and it's easy to read some technical errors into what you wrote here, FYI. But generally, you don't need a 16-bit data bus to load 16-bit words. But you certainly take a penalty having to load two halves of the word across the data bus (like the Z80 does). I'm a little rusty, but it looks like the VDP is setup with 16-bit data access to VRAM. It has pins for a 16-bit data bus with the CPU, but it operates in 8-bit mode in the PC Engine. So when the CPU wants to load tile data into VRAM, it will write them a byte at a time to a 16-bit register in the VDP, and the VDP will write out the 16-bit word. So loading the tile data is going to be a perf hit, but once it's loaded, the VDP can tear through it much faster. But having 64kB of VRAM is definitely nothing to sneeze at, even with later 8-bit systems having 16kB of VRAM (Master System). That all definitely impacts the quality of the sprites (and how many can be on screen at a time) more than the CPU being 8-bit or not. And heck, the 5A22 was a bit of a weird beast, being a 16-bit processor with an 8-bit data bus. To the point that it was sometimes beneficial to put it into 8-bit mode to avoid the second cycle needed for a load/store. But at least you could do 16-bit math on it without contortions. Fun.
  9. Still fair to point out that the ODE behavior of the Mega SD isn't forgiving, IMO, and may have glitches in otherwise "valid" dumps. It isn't like they can point folks at Redump in their official manuals. That gives more reason that they should document the ODE behavior in more detail somewhere official. Even if it is in the developer manual. If only for those of us who don't follow the "preservation" scene closely enough to download someone else's dumps and call it a day. Or in my case, I want to be able to dump my own library and develop a workflow for doing that (so many Windows-centric tools to work from, but I'm not on Windows), but it's a giant PITA if you have to go in blind trying to figure out what parts of the "spec" they support, and what parts they don't.
  10. I received mine today, got to spend some time with it. I use my own backups, so I've been hitting some issues because TerraOnion's manual is very vague on what is expected to work. Using cdrdao to make the copy, and then using toc2cue, I've hit the following issues: Some games which launch fine with my stock US Sega CD get recognized as EU disk images instead of US, and demand an EU BIOS. Not sure exactly what they are using. Games that rely on CD Audio are indexing into the wrong spot in the file. An example is Sonic CD where the first zone starts at the very end of the right track, and then plays into the next track instead of looping. Beyond that, it seems to work fine. But I think the warning is that it is picky about the format of the rip (or the cue), and the manual doesn't give enough details on what it's expecting to know ahead of time what will work. So you are left twisting in the wind trying to figure it out if you are making your own rips. What makes things weirder is that the games recognized as US load and play fine, and the audio isn't corrupted (tracks just don't start/stop in the right place). I don't yet have an EU BIOS to see what happens if I load one of the rips it recognizes as EU. I need to do more testing with a couple different rips to see if I can figure out what's going on. cdrdao rips at 2048 bytes per sector by default, which seems to work, mostly.
  11. I kinda agree with you on the Colecovision. But the SMS cartridge adapter comes in the Mega SG box, supposedly supported. And since they’ve been saying they will also sell cart adapters for SG-1000/3000, MyCard and Game Gear (all very similar to the SMS core)… I don’t think they can really avoid providing support on the SMS side as well unless they want the cart adapters to land like a wet thud and just not sell because the SMS core wasn’t up to the same quality as the Genesis core.
  12. I'm assuming you mean backup without having to remove the card and make a copy manually. I think #1 might be your best bet. Toshiba's FlashAir in particular has an HTTP server running on it, and is documented enough that you should be able to write some scripts to make copies of the files on the card. #3 is a no go since AFAIK, none of the ports offer much access. The USB on the back is power-only. The HDMI port doesn't carry ethernet (it doesn't need it), and the controller ports are electrically identical to the Super Nintendo hardware. #2 is probably doable, but more work than using the FlashAir.
  13. I’m not sure anyone answered your question, so I may be repeating someone’s answer here. The SuperNT and MegaSG don’t support ExFAT (it costs money to license, as one reason). You will want to use FAT32. Sent from my iPhone using Tapatalk
  14. https://gamesx.com/cartouts/gennyport.htm https://gamesx.com/wiki/doku.php?id=schematics:console_related_schematics It isn't like the PSX, where the CD is fully integrated. A cartridge and the Sega CD are both effectively daughterboards, with full access to the address and data buses and signaling lines required to coordinate. Much of what you need is accessible from either set of pins. For the rest, it's possible there's good equivalents/replacements for the FPGA version, or there is in fact a true 1:1 mapping you can build electrically. I'm not sure. But it does look like almost everything you can do with one connection, you can do with the other.
  15. The catch there is if you want to use the HDMI 3D spec, this is mostly true. If you just need to sync up the shutter glasses that came with the SMS, that’s another matter. It should work in the mode where the clock speed of the SG is adjusted without having to actually implement the 3D spec at all. Otherwise the screen tearing would not be nice. The lag the TV adds would probably desync the glasses though, but if you could add an adjustable delay to the signal for the glasses it could be overcome. This is probably the easiest answer, since it should be possible to create a delay circuit controlled by a potentiometer. You can also avoid needing a buffer while supporting the 3D HDMI spec by using the lower resolution side-by-side format versus the frame packed format BD uses. That would just need to be able to output “plain” 1080p30 to pull it off (PS3 does this). But you would need the HDMI scaler to support this form of frame packing directly, and that is something only Kevtris would be able to answer. And it would add a frame of lag as it needs to be fully buffered. This is the “cleanest”, but requires the TV to support 3D glasses, when newer ones don’t. Hah, you beat me.
  • Create New...