MiSTer FPGA Forum

That's nice, to me, I find the idea of the system simulating the spinning disk aesthetically pleasing. Though ideally, it should spin that disk, it shouldn't care what data registers the CPU looks at or anything, no hacks, no nothing -- if the 6502 doesn't read it in time, the byte is just lost. I assume that's what the real hardware does. 6502 wi...

I don't think the SRAM framework is a great fit for floppies, especially on Apple II. The key thing is that there isn't necessarily a 1:1 relationship between program disk and save disk the way that there is for cartridge and SRAM. Some programs only save user data to the program disk itself, some only save to a separate save disk, and some can sav...

I'd have thought, the thing going into 'track_memory' to tell it where to index would be the same for both read and write. Those expressions probably would be similar in a version of the code that supports floppy writes. As it is now, the write path exclusively handles the top-level core filling the track RAM with data from the image file, while t...

The 'phase' stuff in here is pretty weird. Not sure what's going on. It's a simulation of the stepper motor that moves the head between tracks. In this context, "phase" is stepper motor jargon for a set of coils that are energized. The motor won't actually complete a "step" without an appropriate sequence of phases being energi...

I used to have a similar problem with the Neo Geo core (although this was on an older PC monitor with internal speakers, not a modern TV). In that case, the problem was somehow tied to the change in display timings. Switching to another input and back or power cycling the monitor after loading the core fixed it. At some point it stopped happening; ...

Would the Sega Saturn core be interchangeable with the Sega ST-V games? [all assuming development goes as planned of course] ST-V has an extra I/O chip to handle the standard player/coin inputs rather than routing those through SMPC, so it's not just a matter of loading the right ROMs into a Saturn core. That being said, the chip in question seems...

I'm not aware of anything that actually runs directly from cartridge space). KOF and Ultraman? I haven't specifically looked at games, but Sega told developers to never store code in cartridges, and graphics/sound assets would need to be copied to an internal RAM before use. Action Replay obviously runs code stored on a cartridge, but I believe it...

I don't think the Saturn has that much RAM. Would likely be more about bandwidth than capacity Not just bandwidth, but the ability to have consistent access timings with the various concurrent things that are happening. There are 6 physically independent RAMs if I haven't somehow double-counted: CPU async RAM, CPU+SCU SDRAM, VDP1 RAM, VDP2 RAM, fr...

XtraSmiley wrote: ↑Thu Sep 09, 2021 12:28 pm Battletoads was EA, not Konami though!

It's also based on TMS34020, which is a fairly complex chip that not many games used. I doubt we'd see it implemented before the TMS34010-based Williams/Midway hardware (which is a topic for another thread).

It seems like Konami did eventually sort of standardize on the GX System for their 2D games... just in time for the industry's big shift to PlayStation-based hardware. Before then, though, there was a lot of "remixing" of previous boards.

CRTC = CRT controller - i.e. the circuitry which counts pixel clocks to generate HSync, and counts rows to generate VSync. The question is whether or not these get reset with the rest of the system - because doing so will, of course, mean that the screen will lose sync. Yes, what I'm asking about is the behavior of the H/V counters with respect to...

I always assumed that H and V counters in a CRTC should be reset, but the more I think about it the less sure I am that this actually makes sense. Does anyone know what any original hardware does? Basically, I'm not sure there are any upsides sufficient enough to offset the downside of disrupting the sync timings to the display.

When you're running a game, virtually every game post-early-Atari-era has at least one frame of latency baked into the game's engine, which is probably just a result of the sheer fact that there's not really a compelling reason to aim to design a game engine that's so fast and lean that it runs on less than one frame of latency. I think it boils d...

I'm not sure this is the actual cause, but it looks to me like the game uses the H counter from the VDP. As part of the overall game initialization, it reads that register and then advances some RNG-like state that many times. Although the H counter is obviously not a random process per se, I guess the value obtained at the specific time that subro...

It's been a while since I've seen any details about this, but their cartridges have a microcontroller that was rumored to handle some important function for each game (e.g. collision detection or enemy behavior). For these, dumping the standard cartridge ROMs probably doesn't result in a working version of the game. https://wiki.neogeodev.org/index...

I think you skipped by part of what I said. I'm talking about emulators for DOS and Windows 9X. I don't believe there were anywhere near the amount issues with input lag back then. I don't think it's your imagination. Emulators from that time could actually change the video mode and control flip timing through direct register writes or via APIs li...

Just to be clear, I'm not trying to say it wasn't an impressive chip, just that it appears to be much more regular than, say, SID or a Yamaha synth. Basically, it seems like its cleverness had more to do with making 32 channels happen at that price point at that time than it had to do with anything that leaks into the programming model. To put it a...

Maybe I'm missing some subtleties (still an HDL neophyte), but the ES5503 doesn't look all that daunting to me. It's basically an array of 32 almost-identical functional units that seem like pretty straightforward sample playback units. There are some oddities regarding the even and odd members of a pair, and two of the channels not really being us...

I don't think that adapter would really work for the X68000 core. As far as I know, the current core does not actually have a 15.75 KHz output mode, and X68000 in general is not limited to 15.75 KHz modes (the official monitors were tri-sync). You'd probably need something that can crop or downscale an 800x600 SVGA mode to TV resolution.

For handhelds or other more compact/hacky form factors, ULX3S looks really promising, although I'm not aware of any organized core porting effort/framework based on it yet.

Unfortunately, "dead" HDMI ports seem to be somewhat common. I don't have a lot of direct experience with these problems, but from what I've heard the main kinds of failure are: 1) A firmware glitch causing a problem with the port's configuration. In some cases this can allegedly be fixed by resetting the TV to factory default settings, r...

Sarge wrote: ↑Sat Apr 17, 2021 4:22 am It looks like Rastan uses some pretty standard chips: MC68000 and Z80, and a YM2151. Don't know anything about the OKI MSM5205 ADPCM chip, but I suspect Rastan would be quite doable.

Jotego wrote an MSM5205 core. It's used in e.g. Double Dragon, Street Fighter, and Legendary Wings.

I've seen a few stories about packages getting caught in a "loop" between facilities, and I think this happened to the 128 MB SDRAM board that I bought last year. This allegedly happens when there's a surge in parcels and the receiving facility doesn't have room to fully unload a truck. In my case I think it was only delayed 2 or 3 days, ...

I don't know enough about this "feature" to know whether it's the same logic, but someone made a script to work around a similar issue.

viewtopic.php?p=198#p198

I think what you're seeing can be summed up as MiSTer being set up (more or less) like an embedded Linux system rather than a traditional desktop or server distro. As far as the base Linux environment is concerned, the process is to update "the firmware" rather than updating individual packages. There are embedded Linux systems with packa...

So hopefully you can see why I'm confused :P I think there's one main disconnect that has us talking past each other: The post you replied to recommended to "stick to the official MAME". You replied to that as though it just said "stick with MAME", and I was trying to make the point that the "official" part is importa...

MAME for what? Plenty of console drivers in MAME are pretty terrible when compared to Mednafen/bsnes/BlastEm!/etc... As always, the correct answer is "it depends". :P I think the key word there is "official", i.e. actively-maintained upstream as opposed to some fork-of-a-fork that is missing years' worth of fixes and enhancemen...

It's possible that I've misunderstood something because much of my knowledge of this is secondhand, but I think most of the drawbacks attributed to software emulators in recent years are really lingering problems with the transition to desktop compositing in mainstream operating systems. Basically, older operating systems allowed applications to dr...

Newsdee wrote: ↑Sun Mar 28, 2021 4:09 pm Is that Pitch Dark image working for you? I got it to boot, but when I press Return on "B PITCH.DARK",
it just goes back to selecting "PRODOS" (I'd expect it to run).

Is it possible that you changed the CPU type? This sounds like exactly what I see if the CPU type is set to 6502.

The wording of the question is pretty ambiguous, and mixes up MiSTer/non-MiSTer with development/release distinctions. I'm sure srg320 just meant that the structure/definition of the menu will change radically before release, not that it's some non-MiSTer menu mechanism.