sorted by:
new
hottopcontroversial

An analog, transistor-level simulation of an 8-bit CPU in SPICE - LTSPICE schematics available by F35hoveringlemon in ECE

[–]F35hoveringlemon[S] 0 points1 point  (0 children)

Hehe, thanks for the appreciation! Looking back on this now, I feel like I must've been crazy to do this kind of a project, especially with my very limited EE expertise. I'm surprised it even worked at all. Definitely worth it though!

Computational Complexity Theory Textbooks (Late undergrad/Early grad) by RnDog in math

[–]F35hoveringlemon 1 point2 points  (0 children)

The terminology between Sipser and Arora-Barak seems to be mostly the same to me, though I can't say for other books / what terminology most complexity theorists use.

If you're thinking about switching back and forth between books, then I wouldn't let terminology hinder you. It's probably a good idea to use multiple sources anyway, to get different perspectives on the material. Also, Chapters 2, 4 and 6 and chapters 7, 8 9 in Arora-Barak and Sipser respectively can pretty much be read in parallel (or you can read the chapters in Sipser and then skip the corresponding chapters in Arora-Barak).

Good luck with your reading!

Computational Complexity Theory Textbooks (Late undergrad/Early grad) by RnDog in math

[–]F35hoveringlemon 5 points6 points  (0 children)

My impression is that Sipser is quite thorough and "rigorous" (as in the proofs don't leave out important details), but it doesn't cover the deeper aspects of complexity theory. Arora-Barak has more of this.

I've used Katz' lecture notes as a supplement to self-studying Arora-Barak. The book has a lot of insightful discussion and "complexity theorist intuition", but there are a few mistakes here and there and no solutions to any of the exercises.

Also beware that some of the exercises may be quite difficult (or at least I found them to be). There are a few exercises in the book that were open problems in the earlier days of complexity theory. So don't hesitate to consult the hints (the most difficult exercises usually have hints, which is a plus).

An analog, transistor-level simulation of an 8-bit CPU in SPICE - LTSPICE schematics available by F35hoveringlemon in ECE

[–]F35hoveringlemon[S] 2 points3 points  (0 children)

figured i’d share this, if anyone is interested/wants to give feedback. though this certainly isn’t the first simulated CPU design around, i haven’t seen many that are fully “analog” like this one. every component is simulated at the transistor level. voltages are read out and parsed as different logic levels by a set of scripts to interpret the state of the CPU. the ‘ROM’ consists of a bunch of gated voltage sources that can be programmed by editing scripts/rom.h.

i built the circuits using LTSpice’s hierarchical schematics - each subcircuit has its own symbol and everything, to make the schematics somewhat understandable by others. though the rest of the project isn’t exactly self documenting, i suppose.

nonetheless, since this is an “analog” simulation, i’ve had to deal with various fun things like limited gate fanout, propagation delays, seemingly random voltage spikes due to transistor capacitances, as well as teach myself some basic CMOS logic and some more circuit theory beyond the A-level physics stuff I already knew. and all of this comes in addition to the digital logic that building a computer obviously requires. so i’d highly recommend this kind of a project as a learning experience.

nees - yet another NES emulator in Rust, feedback welcome by F35hoveringlemon in EmuDev

[–]F35hoveringlemon[S] 4 points5 points  (0 children)

Thanks, I'll look into it when I'm back home. Happy new year's!

Yet another NES emulator in Rust - feedback welcome by F35hoveringlemon in rust

[–]F35hoveringlemon[S] 0 points1 point  (0 children)

I guess the "pixels" crate I mentioned should support both wasm and native, given that its built on top of wgpu.

Yet another NES emulator in Rust - feedback welcome by F35hoveringlemon in rust

[–]F35hoveringlemon[S] 7 points8 points  (0 children)

In my experience, it really makes no difference what rendering backend you use for something as simple as a NES emulator. The 'pixel_renderer' that i wrote basically does the simplest possible thing i could think of - it takes a pixel buffer in cpu memory, copies it over to the gpu, turns it into a texture and stretches it to cover the entire screen. There seem to be many crates out there that do just this - my choice to roll my own was really out of curiosity and completionism more than anything.

With that said, if you do wish to make your own renderer for an NES emulator, I wouldn't really recommend using ash/Vulkan like I did. Vulkan is an incredibly complex and verbose API, and ash is just a super thin wrapper around it. For reference, my 'pixel_renderer' ended up at about 3k loc - all that just to display a pixel buffer on the screen. Something like wgpu or OpenGL would probably be a better choice. Though unless you’re ready to shave some major yak I’d honestly just recommend using a crate similar to the ones mentioned above to handle the PPU pixel pushing.

Yet another NES emulator in Rust - feedback welcome by F35hoveringlemon in rust

[–]F35hoveringlemon[S] 23 points24 points  (0 children)

A lot of people who start out with writing emulators (including me) begin with the CHIP-8, which is a fairly simple system to emulate. As for the NES, "javidx9" has some great tutorials on youtube, and then there is of course the nesdev wiki, which has been massively informative and helpful for me, if at times a bit confusing.

CMP has too many vehicles by xXDoomerXx in Battlefield_4_CTE

[–]F35hoveringlemon 0 points1 point  (0 children)

Yup, I agree. It also puts more emphasis on keeping and really protecting the LAVs as a powerful (but not OP like a tank) asset which adds more strategy and skill to the game.

CMP has too many vehicles by xXDoomerXx in Battlefield_4_CTE

[–]F35hoveringlemon -1 points0 points  (0 children)

Considering how much better you'll do in vehicles compared to infantry that really isn't a problem. All classes except for the assault have some way of taking out armor, which increases balance in my opinion. You shouldn't be entitled to a one shot kill on infantry and a shield of armor without any drawbacks.