Jump to content

Kitrinx

New Members
  • Content Count

    44
  • Joined

  • Last visited

Community Reputation

104 Excellent

About Kitrinx

  • Rank
    Space Invader
  • Birthday July 11

Contact / Social Media

Profile Information

  • Gender
    Female
  • Location
    Brooklyn

Recent Profile Visitors

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

  1. It did go up recently, from $135 to 170 unfortunately, presumably because of the worldwide parts shortage. The minimum you need to get started is the DE10 for $170, at least 32mb of sdram for $30-60, and a cheap otg usb hub for about $9. This is assuming you already have a usb stick or sd card that you can use for roms. The other boards and case are optional.
  2. Then wtf are you reading this thread for?
  3. Oh, yeah, those don't work well at 240p (when people are using crt's) and take a lot of resources. It's better to look at mister's interface as a fancy flash cart rather than a simple emulator. It's somewhere in between.
  4. MiSTer actually has a screenshot feature, although it's at the original pre-scaled, and pre-aspect corrected resolution. Good enough for passwords though
  5. These numbers are pretty easy to measure. "It feels good to me" is a meme at this point Unfortunately there's no way good way to describe the proper *feeling* of low latency to people, it's something you have to experience to understand why people like it. It's kind of like trying to describe how good the contrast ratio on an OLED looks to someone who hasn't seen it. Using some hacky tricks like runahead you can get the video latency somewhat close to a bare metal system, but the audio and input will still be a bit behind. Again, this isn't a thing that matters to everyone. If you're happy with such things, then keep using those. MiSTer is better than than them on this particular issue though, and we DO have the numbers. I'd like to point out that FPGA people aren't a "cult". Many of us, including myself, use both software and hardware emulators. I think what you are seeing is probably pushback from FPGA people against overly aggressive software people who come into threads about an FPGA core in order to pee in the cheerios. Not naming any names.
  6. Sort of. My TIA audio is basically gate level identical. Some parts can be basically 1:1. However FPGA's do run differently than ASICs, as silicon and FPGA fabric have different properties. You'd never implement some ram on a transistor basis, nor would you want to. Bi directional busses are best to split on FPGA's, and usually clock enables are a good idea to add, rather than allowing things to be clocked directly by arbitrary signals. Some things make no sense to implement at a gate level. Like an adder would be a fairly large circuit that just increments a number, so in HDL you would do something like x <= x + 1; in a clocked block and have the compiler implement the circuit for you. There's no logical difference. I wouldn't even classify it as an abstraction really. It's more like tokenization of boilerplate circuits. Almost none of mister's cores are very heavily abstracted though. The vast majority of them are cycle accurate, and run in real time. Many of them, particularly the consoles, are modeled after decaps or schematics of chips. Unlike software emulators, they can have down to gate level accuracy without using a large powerful pc. There's no penalty for that level of detail since everything runs in parallel like the original hardware did. Properly done low level designs are often more space efficient than large abstractions end up being. In a nutshell, yes, both FPGA's software can be accurate, but because FPGA's work extremely similarly to real hardware, it's *much much* easier to write an accurate emulator. In general, people who develop for FPGA (at least MiSTer) value accuracy extremely highly, and make it a priority. Lastly, an FPGA can run at full accuracy with much less hardware. A software emulator would need an expensive PC to run at a comparable level. Some aggressive advertising from some companies has led to a lot of FPGA myths circulating, so I'll try dispel some in a couple of bullet lists: What you will get from MiSTer: - Low Latency Video. It's bare metal so the FPGA drives the HDMI chip (and analog video) directly. In low latency mode it has roughly 10 scanlines of delay for outputting the picture. - Low Latency Input. An arm core running linux is responsible for the input. It's been measured with an arduino that some controllers can go from button to core in about a half a millisecond. - Low Latency Audio. Most software emulators have to buffer audio for around 35+ milliseconds (about two frames). It's output directly on MiSTer. - Cohesive interface. The UI is simple to save resources and work at original analog resolutions, but the options are consistent and cohesive from core to core. - No power compromises. MiSTer is capable of running emulators at the same level of performance and accuracy as a very high end PC. - Some hardware integration. Things like light guns and original peripherals can work directly with MiSTer. - Easy setup. Most people are intimidated by the appearance of the electronic components, but in reality they just snap together like legos. You flash the mister firmware to an sd card, pop it in, and you're ready to go. It requires less configuration than retropie. What you won't get from MISTer: - Instant, perfect accuracy. While most of mister's console cores are at or above the accuracy level of their most highly regarded software counterparts, it's not implicit that they will be written that way. It's easier to make a core accurate in HDL than Software though. - Fancy flashy UI's that scrape your ROMs and show you little pictures of everything. MiSTer has no GPU, so the FPGA has to use resources to process such things, which is not worth taking away from the cores themselves. - Some features. The most common one people miss is save states. While a few cores now have save states, most don't, because they are difficult to add in fpga designs. Also missing are things that don't work like original hardware could, like high resolution modes, 80mhz booster chips, etc. - Cart slots. There's not enough GPIO on the board for them, and part of the goal of the project is to remove the need for discontinued hardware. If you're happy with software, use software. Some people don't care if their pi has a frame skip once in a while or whatever, and that's fine. It's great that these old games can be so accessible. I would say MiSTer will appeal most to people who want something very close to a real-hardware experience with a bit more quality of life and stability than real hardware can provide reasonably. It's certainly an enthusiast-level device, but it DOES have differences and advantages. It's quite subjective whether they will be worth it to any given person or not though.
  7. 7800 is already released, and pretty feature complete. If you are a CRT gamer, it might be amongst the best ways to play the system right now. There is also an existing 2600 core which is pretty capable, but not as feature complete as it could be, which is why I'm working on it. There's cores for 5200, ST, and Amiga as well which are well regarded. The Jaguar core is in sort of a pre-alpha state and development isn't active on it. Several Atari arcade machines are also represented, but I couldn't say how well regarded they are.
  8. Intellivision? I don't even think I'd be willing to open that console in my text editor Maybe you're thinking of Grabulosaure, he wrote an intellivision core that is pretty mature. I am generally not involved in any arcade related things, Alan is who you want to talk to there. I mostly deal with 3rd+ gen consoles. 2600 is kind of an exception for me, which I got tangled up in because it's such an integral part of 7800. It's best to make sure people are actually working on things, and not just saying they're working on them. A lot more people start things than finish them, so there's plenty of orphaned things with old comments where people say they're working on it.
  9. My experience is with intel FPGAs. Quartus doesn't complain at all about using VHDL functions like that, as long as the source is properly assigned as VHDL in the qip file.
  10. There's at least a few existing implementations that could be used for this purpose I would think, if someone cared to design it with a little max10 or something.
  11. Having worked on both, of these, and many other system, I can say 2600 is one of the most absolutely unforgiving systems in terms of being cycle and sub-cycle accurate. It's not just that the system itself had a tremendous number of quirks, but the programmers who wrote for it were (and are) aggressively hacky, using every scrap of every cycle and every idiosyncrasy they can find to their advantage. NES is difficult because of its 1001 mappers and the complexity and bugs in the PPU and APU, but ultimately it's a lot more forgiving.
  12. I meant you no disrespect at all, your implementation was very thorough and the parallels to the schematic were clear and well observed, but I had my own TIA partially written since 2019 and it had clock enables already, and I find it fun. Sometimes the best way to really understand a system it to write it yourself. I did try to use yours for a bit, but I had issues with the clocking and I have a special hatred for working with VHDL
  13. That's not unusual. Simulation can be quite a pain in mixed language projects.
  14. HALT is a signal that is specific to the 6502C aka "Sally" used for 7800, and you don't have to worry about it. RD is simply the RW signal, Read is high, write is low. Pclk1 is phi1 and used the drive the clock of the cpu. If you are generating a clock directly, you would want to make "enable" 1 and feed your clock as the clock signal. In my case I give it the system clock (14mhz) and use a 1-cycle-long clock enable to gate the timing of the CPU. To keep it simple for you, I think you should just skip the enable and use your cpu clock directly as the clock.
  15. Under the circumstances, I wouldn't worry about shifting phases. As long as you know to have a separate delayed clock for your peripherals you're okay. The alignment of the cpu clock and the internal TIA clocks also matters, but I also wouldn't stress too much on that right now, until after you have it end to end. I should also add that the TIA in my project is not complete and shouldn't be trusted as a reference for some parts. The audio, and parts of it used by 7800 are tested and working well, but I punted the HMOVE and other graphics drawing to after release, so I could work on it separately (right now).
×
×
  • Create New...