|
Crossposting from the Making Games thread: Shaders work in battle!
|
#
?
Mar 20, 2014 01:11
|
|
|
|
| # ? May 9, 2024 19:23 |
|
|
Putting the finishing touches on the control panels for my roguelike submarine sim:
|
|
#
?
Mar 20, 2014 11:55
|
|
|
The Geoff posted:Putting the finishing touches on the control panels for my roguelike submarine sim: Holy crap this is awesome! What platforms are you releasing it on?
|
|
#
?
Mar 20, 2014 14:29
|
|
|
Trying to make a simple order-book UI over Interactive Broker's API in Clojure. With this project I'm trying to wrap my head around core.async which seems cool, and also Swing which seems like an annoying necessary evil, even with the Clojure library Seesaw. The thing is still pretty shoddy (there are visible errors in the screenshot like multiple table entries for the same price and that "Symbol" field that just has a date in it for no reason), and I'm definitely doing UI updates in a lazy horribly way that I need to fix. But the async stuff seems to be working pretty nicely, and it's pretty satisfying watching this thing update in real time so I felt like posting a screenshot. I'll post any progress here if anyone cares (and probably if no one does too).
|
|
#
?
Mar 20, 2014 16:52
|
|
|
Pseudo-God posted:Holy crap this is awesome! What platforms are you releasing it on? Thanks! It's PC only, and it's written in an old version of Blitz Basic so it'd be tough to port it to any other platform. Maybe one day. It's called Sub Commander, you can find it here: http://www.subsim.com/radioroom/showthread.php?t=202304
|
|
#
?
Mar 21, 2014 00:18
|
|
|
If you're building the firmware for a game console, it would be nice to actually make a console out of it, right? Right. I'm about halfway done getting this 3-D printer together. It can print a contiguous volume of about a cubic decimeter (a 4" cube, roughly), so that should be enough to print an SNES cartridge casing around the outside of a BeagleBone Black:  ... or a teeny-tiny SNES:   I've managed to merge in GBC/GBA and NES emulators into the GUI front-end, so I can potentially have a console that plays GB*/NES/SNES all together using the original SNES controllers. Unfortunately, all emulators except the SNES emulator are GPL, so I can't build the SNES emulator directly into the GUI alongside the other emulators. I'll have to either switch to a different SNES emulator (unlikely) or do a fork()/execve() to launch it like a shell would and then have the GUI hang out in the background while the SNES emulator does its thing. I have purposely avoided doing this because it is much slower to launch than having everything built together into a single binary.
|
|
#
?
Mar 21, 2014 16:03
|
|
|
hendersa posted:I'm about halfway done getting this 3-D printer together. It can print a contiguous volume of about a cubic decimeter (a 4" cube, roughly), so that should be enough to print an SNES cartridge casing around the outside of a BeagleBone Black:
|
|
#
?
Mar 21, 2014 16:25
|
|
|
I hope you end up making and selling these.. I'd very much like to buy one off you.
|
|
#
?
Mar 21, 2014 16:27
|
|
|
The only thing that makes sense now is to make the BeagleBone a device that plugs INTO a cartridge.
|
|
#
?
Mar 21, 2014 18:28
|
|
|
I kind of want to layout a custom board for that now that would slot even better even into an existing SNES cartridge or something...I just finished another 0.4mm and 0.5mm pitch BGA board, so it doesn't even faze me anymore (I am dead inside). I hope TI is giving you something for doing all this.
|
|
#
?
Mar 21, 2014 18:36
|
|
|
iopred posted:The only thing that makes sense now is to make the BeagleBone a device that plugs INTO a cartridge. Baby steps. I need to get the controller interface and full emu core working, first. Then, I can start looking at using a bank of latches with level conversion to talk to all of the cart pins (the carts use 5 volt signals, and the BBB uses 3.3 volts). I can yank a lot of ROM logic out of an emulator and go straight to the cart to get what I need. I think that when I start going down this route I will start with a Gameboy emulator and use the original GB carts. Then step up to NES. Then SNES. movax posted:I kind of want to layout a custom board for that now that would slot even better even into an existing SNES cartridge or something...I just finished another 0.4mm and 0.5mm pitch BGA board, so it doesn't even faze me anymore (I am dead inside). I doubt they care. Aside from you folks, no one seems real interested. I submit my work to Hackaday as tips now and then and nothing ever comes of it. I think they are too busy showing how to turn old hairdryers into toasters using an Arduino. Most of the exposure my work gets is via OSS release announcements via RSS feeds. The BBB is backordered everywhere right now, so the board isn't in enough hands right now to have a critical mass of interest in my work. Mostly just a few scattered hobbyists, anyone trying to build a homebrew Android system, and you folks. If you manage to compile something on a Raspberry Pi, people trip over themselves to mention you on a dozen websites and you get exposure to a lot of different people that want to compare notes with you about your work. If you do something with the BBB, you generally just hear crickets back or have people begging you to help them troubleshoot why their HDMI connection isn't working. It is tough to develop this stuff in a vacuum. I can only hope that I figure out all of the "tough" pieces, am able to sufficiently document it all, and am able to help bootstrap other developer efforts once the platform picks up some steam. 
hendersa fucked around with this message at 19:50 on Mar 21, 2014 |
|
#
?
Mar 21, 2014 19:37
|
|
|
hendersa your poo poo is cool as hell and I think the effect you're seeing isn't so much due to the lack of traction of the BBB platform as it is due to one of the corollaries of the bikeshed effect - nobody talks about the nuclear power plant getting built because they don't have a clue how to design something of that scale and complexity. As an aside, have you considered putting all your project updates and documentation on a dedicated blog in addition to posting them here?
|
|
#
?
Mar 21, 2014 19:44
|
|
|
As somebody who knows absolutely nothing about hardware design, but is interested and wants to dick around, what would you recommend for a beginner?
|
|
#
?
Mar 21, 2014 19:48
|
|
|
hendersa posted:Baby steps. I need to get the controller interface and full emu core working, first. Then, I can start looking at using a bank of latches with level conversion to talk to all of the cart pins (the carts use 5 volt signals, and the BBB uses 3.3 volts). I can yank a lot of ROM logic out of an emulator and go straight to the cart to get what I need. I think that when I start going down this route I will start with a Gameboy emulator and use the original GB carts. Then step up to NES. Then SNES. It says volumes about how lovely the HAD editors are these days if they're ignoring your submissions; there's a lot of dumb poo poo that makes it up there.
|
|
#
?
Mar 21, 2014 19:53
|
|
|
Otto Skorzeny posted:hendersa your poo poo is cool as hell and I think the effect you're seeing isn't so much due to the lack of traction of the BBB platform as it is due to one of the corollaries of the bikeshed effect - nobody talks about the nuclear power plant getting built because they don't have a clue how to design something of that scale and complexity. Thanks! I thought about a blog, but then I decided that my work is so sporadic that I'd just rather talk directly to you guys and then publish awesome documentation later. I give little updates on my Google+ page sometimes with pictures, screenshots, YouTube clips, etc. Suspicious Dish posted:As somebody who knows absolutely nothing about hardware design, but is interested and wants to dick around, what would you recommend for a beginner? I'm picking it up as I go. I honestly look at schematics for cape boards and the like and then pick off chunks of the design for my own use. I think that the Embedded Programming thread might be a good place to ask on how to get started, since that has people with a wide variety of hardware/software co-design backgrounds. I poked my head in there once, opened my mouth, and was called an idiot, though, so I think I'll just hang out here with you software guys. To be honest, I started with Getting Started in Electronics back around 1985... movax posted:It says volumes about how lovely the HAD editors are these days if they're ignoring your submissions; there's a lot of dumb poo poo that makes it up there. Well, they know what they want at HAD and they stick with it. My work is probably too software-oriented for their interest. Throw an oscilloscope or a PCB in there and they'd probably be all over it, though. They really tailor their write-ups for the "maker" folks that like to build physical things. I guess I shouldn't be all doom and gloom about this sort of thing, though. beagleboard.org does mention BeagleSNES right there on their front page, so that's nice of them. Adafruit made BeagleSNES a winner in their BeagleBone Black case contest (and they made My Rhythmic Crotch's LCD driver tinkering a winner, too!), so people do notice it from time to time. But, I'm trying to reach some more experienced developers doing the same type of work that I am, and I'm just not finding them. Even the BeagleBoard Google group is more of a support forum. The hardcore developers are mostly cribbed from the Linaro staff or are interested in developing Bonescript. Anyway, back to the screenshots! I want to see some more submarine sims! 
hendersa fucked around with this message at 20:18 on Mar 21, 2014 |
|
#
?
Mar 21, 2014 20:14
|
|
|
hendersa posted:I have purposely avoided doing this because it is much slower to launch than having everything built together into a single binary. What is the cause of the slowness? Is it the exec call itself, loading the env and such? Could you modify the other emulators or make a GPL wrapper that would allow you to fork/exec right away, but wait for commands from the main process to actually run & halt the emulator?
|
|
#
?
Mar 21, 2014 20:17
|
|
|
taqueso posted:What is the cause of the slowness? Is it the exec call itself, loading the env and such? Could you modify the other emulators or make a GPL wrapper that would allow you to fork/exec right away, but wait for commands from the main process to actually run & halt the emulator? It is the release and rejuggling of video and audio resources. The framebuffer isn't too robust, so I actually have to shutdown parts of SDL during the forking process and restart it in the child. This leads to screen flickering and sometimes even a brief moment where you can see a text login screen. I might be able to mitigate this with some clever chvt action (fork, execve the shell, execute a shell script that launches the emulator, etc.) I rip out the video init code from the emulator, set up the most optimal config in the GUI front end, and then roll straight into the emulator code from there. I used to use the GUI as the init process for the system for fast booting, but now I use a shell script that does a few setup things before rolling into the GUI, so I have some more flexibility when it comes to forking child processes.
|
|
#
?
Mar 21, 2014 20:24
|
|
|
hendersa posted:Baby steps. I need to get the controller interface and full emu core working, first. Then, I can start looking at using a bank of latches with level conversion to talk to all of the cart pins (the carts use 5 volt signals, and the BBB uses 3.3 volts). I can yank a lot of ROM logic out of an emulator and go straight to the cart to get what I need. I think that when I start going down this route I will start with a Gameboy emulator and use the original GB carts. Then step up to NES. Then SNES. Not to be a dick since I know you're already in way deep on the Beaglebone Black but why'd you go with the Beaglebone Black and not the Raspberry Pi? Didn't the pi already have a way bigger community when you started? And have you considered attracting attention via kickstarter? If you build a case that looks like an SNES cartridge, plugs into a TV and an SNES controller, and demo it, I think that'd be a pretty hot demo and you'd get kickstarter funds to continue your work and attention (because blogs pick up stuff that is hot on kickstarter).
|
|
#
?
Mar 21, 2014 22:34
|
|
|
Dren posted:Not to be a dick since I know you're already in way deep on the Beaglebone Black but why'd you go with the Beaglebone Black and not the Raspberry Pi? Didn't the pi already have a way bigger community when you started? Not a problem. There are a few reasons: 1. The BBB (running at 1 GHz) has more processing power than the RPi (running at 700 MHz). I wanted to work with a more powerful platform and see what I could push it to do. I've had several people comment that BeagleSNES runs better than SNES9X-based SNES emulators on the RPi. RPi is well-suited to settop box-type tasks, like running XBMC, because it has special hardware for that sort of thing. The BBB can't do this sort of stuff, but it has some solid raw processing power to work with. 2. The BBB has far more I/O flexibility for peripheral interfacing. Take a look at the RPi's interfacing header pins for a sec:  If you shut off all of the bells and whistles, you have 17 GPIO pins to play with (15 by default, since P1-8 and P1-10 are mapped as a UART at boot). For the BBB, you have the following:  That's a whopping 31 GPIO pins available to work with by default. Plus, you have an I2C channel turned on by default (pins P9-19 and P9-20). For the RPi, you sacrifice a few more pins to mux the GPIOs into I2C pins. For the BBB, you can even disable the HDMI video for headless applications and free up another 24 pins to use as GPIOs, another I2C channel, another SPI channel, etc. (That second image is from an article of mine on the BBB that is published in the current issue of Raspberry Pi Geek Magazine  )3. It is the "wild west" in the BBB community at the moment. This is both good and bad. The good is that I have an opportunity to provide a greater amount of benefit to the community of users. That's why I spend so much time trying to do stuff like getting Android working on the board. The bad is that I spend a lot of time diagnosing and fixing kernel hiccups and finding creative work-arounds for stuff. The RPi really sucked up a lot of the talent in this space, so I just happened to find a niche in the (much smaller) BeagleBoard community. 4. The AM3359 processor has two "real-time units" built into the chip. These are like two 200 MHz processors that do their own thing, independent of the main processor, with a 5 ns execution time for every RISC-like instruction. You can control GPIOs like a microcontroller does (a fast microcontroller) by downloading code into these units at runtime. I haven't even scratched the surface of these things yet, but I hope to use them to bitbang an interface to the controllers, rather than use an intermediary PIC microcontroller to do the timing-sensitive interfacing. If you are clever with the real-time units, you could potentially offload quite a few processor cycles from the main processor and put those extra cycles into the performance of userspace software. The RPi is a really good platform for its pricepoint, and I'd certainly recommend it to anyone, but I'd like to push the more-flexible and powerful BBB and see what I can make it do. quote:And have you considered attracting attention via kickstarter? If you build a case that looks like an SNES cartridge, plugs into a TV and an SNES controller, and demo it, I think that'd be a pretty hot demo and you'd get kickstarter funds to continue your work and attention (because blogs pick up stuff that is hot on kickstarter). If I were to do a kickstarter, it would be to fund me to write a book on this stuff. All of the code, schematics, documentation, etc. I have been, and will continue to, release for free to help spread the knowledge around. I keep a lot of notes, so I have a ton of material here already from my experimentation. I could probably write a book by scraping together all of the reply mails that I have sent to people that have asked me questions over the last year! I'm not really interested in going through the logistics of preparing and selling a physical product of some sort. But, if I could justify the work for a book, or even just an e-book, that might be worthwhile. I'd have to find the time to do it, though! For me, working with the BBB is more about the journey, rather than the destination. So far, it has been a pretty drat eventful trip. hendersa fucked around with this message at 02:21 on Mar 22, 2014 |
|
#
?
Mar 22, 2014 01:55
|
|
|
Pretty much got this thing finished. Blaster bomb in action:  Rocket duel with a tank ends badly:  Mind control shenanigans:  Feeding rookies into the meatgrinder: 
|
|
#
?
Mar 22, 2014 16:37
|
|
|
hendersa posted:To be honest, I started with Getting Started in Electronics back around 1985... Forrest M Mims III  I've got all of those mini notebooks that focus on basic electronics concepts. So legit.
|
|
#
?
Mar 22, 2014 18:55
|
|
|
I'm back to writing shaders. Have some shadow mapping, deferred lighting and screen space ambient occlusion.
|
|
#
?
Mar 23, 2014 17:34
|
|
|
Got the printer up and running. I built it myself out of wood and zipties.  https://www.youtube.com/watch?v=pRcUl4G0SbE I'm still getting the hang of the software, but the calibration is going well and I'm starting to think about printing BeagleSNES housings...
|
|
#
?
Mar 25, 2014 03:23
|
|
|
Fractals!   
|
|
#
?
Mar 25, 2014 03:25
|
|
|
More lame Android stuff from a worthless noob, this time on the   I had posted about this before, only in C#. Decided to try a simple port to Android alongside the math quizzer I posted earlier. It's very basic, and I'm thinking I should just dump the buttons and have the menu button reveal copy actions. The user could just touch the color to generate a new one. I need to add Hex, which shouldn't be difficult. I have a WIP version that stores the last twenty colors (stored as ints) to an array, which hypothetically would allow a user to swipe right to go back to the last color they generated. I've got to work on that, but I'm getting married in a little over two weeks, so that probably won't come for a while. The most frustrating part of this was figuring out how to copy to the Clipboard. There's an old API entry called ClipboardManager that is deprecated. I went online to try and figure it out and I found all these references to Clipboard Manager, so I put it into Android Studio, only to be met with an error that what I was trying to use was deprecated. Took me a bit of hunting, but I ended up finding out that, in fact, what I was supposed to be using was this ClipboardManager which is a child to the old ClipboardManager and identically named and ugh why do that?! I'm sure the reason is well informed and beyond my scope of knowledge, but surely they could have at least named it something different or put a note in their own IDE that says "hey we replaced this with an identically named object, please see <url> for more info." *not an attempt to solicit/promote
|
|
#
?
Mar 25, 2014 16:05
|
|
|
Literally Elvis posted:More lame Android stuff from a worthless noob, this time on the should have an option to show the rgb/hsv/hex instead of copying it.
|
|
#
?
Mar 25, 2014 22:24
|
|
|
Hahaha some of those reviews are great.
|
|
#
?
Mar 26, 2014 01:42
|
|
|
munce posted:Pretty much got this thing finished. I pretty much love you
|
|
#
?
Mar 27, 2014 13:53
|
|
|
I've been working on a solution for a problem with my Dual Contouring ("voxels") renderer. The terrain is split into a grid of "chunks" which are processed individually. This means the generation of the mesh can be run concurrently (each chunk generates a mesh), and when the volume is modified only the local area around the change needs to be updated. Logically the entire volume is sampled when the mesh is generated but as each chunk is entirely self contained, gaps appear in between the meshes where nodes from separate chunks are adjacent, but can't be considered when generating the mesh as they belong to entirely separate octrees. Each mesh is a separate octree:  One very crap way to solve this is to take the root nodes of all the chunks and construct a global octree and then just generate the mesh from that. That will run into all sorts of problems as the only way to update part of the mesh is to regenerate the whole thing! A better solution would be to find only the nodes which are on a chunk boundary and construct the global octree only from these nodes. Now you have something to draw in between all the chunks, but if you need to regenerate a small part of the seam, the whole volume has to be considered. I've improved on that by realising that for any given chunk, only the nodes which appear on the 3 'maximum faces' (i.e. the faces where x=max.x, y=max.y, z=max.z) need to be considered for the seam which connect that chunk with its neighbours. Each chunk becomes responsible for a small piece of the entire seam, and the individual pieces interlock to create the global seam. This is very handy as it means that any changes to the volume will only require the area local to the change to be regenerated. Chunks are grey, each chunk seam has a different colour:  And textured:  Here's a bird's eye view of the interlocking: 
|
|
#
?
Mar 28, 2014 01:52
|
|
|
hackbunny posted:I pretty much love you Thanks! Can i ask what made you like what you saw? how much was based purely on nostalgia for the old game vs the gameplay shown? I know that when i started this project i was trying to recapture some of that 90s feel (hopefully with some upgrades).
|
|
#
?
Mar 28, 2014 16:35
|
|
|
Been taking a break from programming and working on some art assets for my game -- feels so nice to be doing something other than code at the moment. 
|
|
#
?
Mar 29, 2014 00:53
|
|
|
hendersa posted:[Awesome The closest thing we have to an embedded board of roughly the same design space (and I mean really roughly) is the E-102, but as an FPGA board it's still fundamentally a different ball of wax. Internally another engineer has gotten PetaLinux up and running on it, but I don't think PetaLinux is a thing actual Linux users/hackers care about. I wonder what I might be able to do with an E-102 along with a BBB in some sort of weird Frankenstein conglomeration, though. EDIT: hendersa posted:I'm picking it up as I go. I honestly look at schematics for cape boards and the like and then pick off chunks of the design for my own use. I think that the Embedded Programming thread might be a good place to ask on how to get started, since that has people with a wide variety of hardware/software co-design backgrounds. I poked my head in there once, opened my mouth, and was called an idiot, though, so I think I'll just hang out here with you software guys. EDIT Mk. 2 (EDIT HARDER!): hendersa posted:But, I'm trying to reach some more experienced developers doing the same type of work that I am, and I'm just not finding them. Even the BeagleBoard Google group is more of a support forum. The hardcore developers are mostly cribbed from the Linaro staff or are interested in developing Bonescript. BoneScript posted:BoneScript is a Node.js library specifically optimized for the Beagle family and featuring familiar Arduino function calls, exported to the browser. Get started exploring the BoneScript Library to discover the great simplicity that is made possible by utilizing Linux. 
minidracula fucked around with this message at 03:35 on Mar 29, 2014 |
|
#
?
Mar 29, 2014 03:26
|
|
elided here... go read his post!]
|
hendersa posted:For me, working with the BBB is more about the journey, rather than the destination. So far, it has been a pretty drat eventful trip. I'm looking to use a BBB to control some steppers (via Pololu controllers), but I can't figure out what C library I should use to interface with GPIO. Everything I found seems to be cribbed together or just thin wrappers around the filesystem interface. I must be missing something. I'm hoping to find something like the bcm2835 C library for raspi. Also, what's the best distro if I just want a basic headless environment, should I just use the stock angstrom?
|
|
#
?
Mar 29, 2014 07:06
|
|
|
minidracula posted:I only speak for me, but I think you should come back to the thread, or at the very least, lurk. I vaguely recall the back and forth you mention (but I didn't go digging through the thread to confirm), but I for one would be happy to have you participate in the thread. A lot of the topics are usually around smaller systems (e.g. microcontrollers), but there's a lot of 32-bit system chat too (ARMs, et al.). quote:Uncomfortable Gaze posted:Hey, I got a stupid question: 1. Use userspace code to talk to the GPIOs via the file system. Pro: Easy to do. Con: Very slow. 2. Use userspace code to talk to the GPIOs via mmap()'d GPIO registers. Pro: Thousands of times faster than file system IO. Con: Can be difficult to set up and troubleshoot. 3. Use kernel code to talk to the GPIOs via a driver. Pro: Much tighter timing guarantees. Con: You have to write a kernel module. 4. Use a PRU (real-time unit) to talk to the GPIOs via the GPIO registers. Pro: Absolute timing guarantees. Con: Difficult to develop and troubleshoot PRU assembly code (you'll need an oscilloscope to watch the GPIOs). In your case, I'd recommend starting with #2. You can find some code to get started here. That code does the setup, so you should be able to get up and running quickly. You'll need superuser privileges to mmap() that memory space, so run your binary using sudo. I've seen people using #4 for controlling stepper motors for CNC purposes, and that is the "ideal" way to go about doing this. When using userspace code to control more timing-sensitive things, be sure to nice the userspace process to -20 to ensure that it is given priority for scheduling. I do not recommend that anyone use the stock Angstrom that comes installed on the BBB's eMMC beyond the initial playing with the board to ensure that it works. That distro is OK for what it is for, but you should really be booting to a microSD card with a different distro if you are doing any sort of serious development. You can build Robert Nelson's filesystem image with a 3.8.x kernel and install it to a microSD card for your development. Grab the small flash image (64 MB, I think) to start, and then apt-get any tools and libs that you need from there. This will skip all that X-Windows crap and give you just a base install to work with for headless applications. You will have to build the microSD card image yourself, but all of these steps are stuff that you'll need to understand if want to make full use of the BBB for a single-purpose custom app.
|
|
#
?
Mar 29, 2014 15:37
|
|
|
hendersa posted:cool stuff Thanks! That definitely points me in the right direction, and I'll probably play with that PRU if I get a chance. I haven't built a distro image in while, this could be fun. You weren't kidding about this being the wild west. I didn't realize we had a separate embedded thread so I'll take any further questions there.
|
|
#
?
Mar 29, 2014 18:26
|
|
|
Probably the worst part of developing nice multimedia software on embedded systems is the profiling process to squeeze out those extra cycles: I've been banging away with gprof to generate timing info for callgraphs of various emulators. In most cases, I've gotten things running about 15% faster after some hand-tuning. You'd be surprised how much you can improve performance by rearranging code, moving variables outside of loops, moving variables inside of loops, and lots of other really counter-intuitive stuff. But, if you move something, profile, and see an improvement, it is a good exercise to sit down and figure out exactly why that is the case and how you can use the same trick elsewhere. Anyway, here is a video of the Game Boy Advance and Game Boy Color running on the BeagleBone Black: https://www.youtube.com/watch?v=5kjJrflm5mU I need to sit at the name entry screen in Advance Wars for a bit to gather some good profiling samples, since that hits the processor hard with the background tile operations. That might point me towards the data that I'll need to boost the low-end performance of the GBA emulation (about 10 FPS, at the moment).
|
|
#
?
Apr 1, 2014 06:05
|
|
|
I finally recorded a video of my final end-of-year project for first year at uni (out of two) last year. Last year was 2D and this year is all 3D but I'm still pretty proud of the result. We had four weeks to make it and I was in a team of two with one other programmer (no artists, I took over as art director and design) https://www.youtube.com/watch?v=3zLvCTY1Y4U&hd=1
|
|
#
?
Apr 1, 2014 08:22
|
|
|
hendersa posted:I'm picking it up as I go. I honestly look at schematics for cape boards and the like and then pick off chunks of the design for my own use. I think that the Embedded Programming thread might be a good place to ask on how to get started, since that has people with a wide variety of hardware/software co-design backgrounds. I poked my head in there once, opened my mouth, and was called an idiot, though, so I think I'll just hang out here with you software guys. I may have been guilty of that in that particular thread, but please if you or anyone see that happening, hit the report button or PM me. I really want to see more in-depth technical projects grown out of these forums, or at least documented here. hendersa posted:1. Use userspace code to talk to the GPIOs via the file system. Pro: Easy to do. Con: Very slow. The PRUs are really interesting, did not realize they were a part of the SoC architecture; I want to read up some more on them. I usually start with #1 when first bringing up a system, but then yeah, it's very trivial to write a kernel module to expose the GPIOs via mmap_to_user() or just ioctls. minidracula posted:The closest thing we have to an embedded board of roughly the same design space (and I mean really roughly) is the E-102, but as an FPGA board it's still fundamentally a different ball of wax. Internally another engineer has gotten PetaLinux up and running on it, but I don't think PetaLinux is a thing actual Linux users/hackers care about. I wonder what I might be able to do with an E-102 along with a BBB in some sort of weird Frankenstein conglomeration, though. Goddamn, I could have used that module a few months ago  PetaLinux was bought by Xilinx as I'm sure you know, and they're big with the folks doing Linux on MicroBlaze and now the Zynq; I've been pretty happy with Xilinx Linux so far. Patches come fast from their guys (I'm pretty sure they hired on Michal Simek as soon as they humanly could), they reply to e-mails (I emailed them saying thanks once, and they replied back with their phone numbers and confusion that someone was willing to say 'thank-you'), and they're generally on top of their poo poo. mnd: how many layers is the EX-800?
|
|
#
?
Apr 1, 2014 20:53
|
|
|
hendersa posted:I've been banging away with gprof to generate timing info for callgraphs of various emulators. In most cases, I've gotten things running about 15% faster after some hand-tuning. You'd be surprised how much you can improve performance by rearranging code, moving variables outside of loops, moving variables inside of loops, and lots of other really counter-intuitive stuff. But, if you move something, profile, and see an improvement, it is a good exercise to sit down and figure out exactly why that is the case and how you can use the same trick elsewhere.
|
|
#
?
Apr 2, 2014 07:54
|
|
|
|
| # ? May 9, 2024 19:23 |
|
|
Scaevolus posted:Did you have a look at gpsp? It's less mature than VBA, but has more aggressive optimizations (including a dynarec). I'll check it out. Thanks! I'd like to look at the ARM support in that to see how well it works as a trade-off between compatibility and performance. If it turns out to have really good performance, though, I might just roll it into the project.
|
|
#
?
Apr 2, 2014 15:31
|
|