This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - willrandship
Pages: 1 ... 17 18 [19] 20 21 ... 208
271
« on: September 10, 2013, 02:53:42 am »
Another problem is the lack of easy inter-person development. The languages aren't designed for it, but that's mainly because the calculators aren't suited for it. Every time you want to update your code, you have to hook into a computer and manually add the new files, and if you've made your own changes to the same files you have to consolidate them. (And no programming language available for the calcs makes this easy.) On PC-side development, synchronizing development work is as easy as (insert svn/git/hg sync command here) and it easily branches into several different development areas, but for calculators such methods are not really an option. (Please don't misunderstand. Axe and Grammer are great, but they're designed for a platform that's not a great choice for community programming. Maybe calcnet could get something going, but size is still a limiting factor.) Also, I'm a terrible project leader.  I don't work consistently on any one project, so I don't manage them well enough for others to do so.
272
« on: August 28, 2013, 10:59:23 pm »
Well, AFAICT the amiga used an IDE-like interface for its hard drives, so it wouldn't be terribly difficult to adapt that to CF cards and use another PC.
273
« on: August 26, 2013, 11:10:46 pm »
Is Dance Dance Revolution old enough to count? 
274
« on: August 26, 2013, 03:38:52 pm »
ElementCoder, let's say you're trying to do software bit-banged asynchronous serial. The timings on that are very precise, so an interrupt would screw it up bad enough to get at least one bad byte, probably two.
Also, maybe you don't want to be able to pause during a transition, or similar. If pausing was interrupt-based you would either need to check if it was a transition, or disable the interrupt.
275
« on: August 18, 2013, 10:22:26 am »
Here's a filtered list of the features that really matter on the nspire. I did remove some stuff that's technically useable, but unlikely to be used, like multiple audio device support. (Easy enough, but I don't know how much audio the USB can handle when you have 4 USB audio dongles ) Look at this list as motivations for why to switch. - Atomic operations (For those who don't know, this is making certain areas of code unable to be interrupted. So, they would postpone any automatic timed actions.)
- Better keyboard support (scancodes vs keycodes, etc).
- A "really powerful" assert macro. (Debugging tool. Not generally used in release programs)
- Power management (exposes battery life remaining, etc) (Could be very useful, assuming it works on the nspire at all )
- 32-bit audio (int and float)
The window-based changes don't matter since even if you use X, there's only 320x240 pixels to work with anyway.
276
« on: August 18, 2013, 09:34:40 am »
I have a theory.
The first layer was probably originally going to be a transparent foreground. That would mean it would be scrolling the right way, and it should be fairly fast. However, it's very noisy and detailed for a foreground transparency, so they moved it back a layer and turned off transparency, without adjusting anything else.
277
« on: August 17, 2013, 07:22:30 pm »
The only really solid things about the project currently are: ez8 micro: get a 64xx series one, please. The 082A series is smaller, but has an internal oscillator. However, the difference in flash causes several problems for programming for cross-compatibility. speaker: Get one. It will probably be hooked to the propeller, but that could change. SD card: See speaker. Same reasoning. Keyboard: Get a PS/2 female port unless you want to chop off a plug. Other than that, it's hard to guarantee anything. Most of the other circuitry won't affect compatibility, as long as it works. Video is a difficult question, since LCDs cost a lot of money (read: >$15 for anything good) and the propeller supports VGA and Composite out of the box. Right now, we're thinking VGA, with various text and graphics modes the propeller will handle. For example, text mode with customizable fonts would make for an easy monochrome tile system, and there will probably also be a color tile system. There will definitely not be a direct 24-bit color bitmap mode, since that would take 230 KB just for a 320x240 resolution, and the propeller chip only has 32 K total. Text modes can be much higher resolution, though, as can certain drawing-based methods, if someone codes them The method for interfacing the ez8 to the propeller is still being discussed. The ideal, in my opinion, would be a shared RAM area. By using an SPI RAM chip (32k or so) or perhaps by making the propeller's 32k RAM space available over SPI, the graphics could be implemented in a framebuffer, and other devices could be handled simply by writing the correct byte.
278
« on: August 17, 2013, 08:23:15 am »
This video is a little scant on the details, but it gives a vague idea on lots of stuff relating to it. This blog post goes into detail on how the polynomial counter works, including the atari assembly. http://www.samiam.org/blog/20130606.html
279
« on: August 16, 2013, 10:17:52 pm »
It's similar to the method Pitfall for the Atari 2600 used. End result in that case: 56 bytes for a 256-byte map.
280
« on: August 16, 2013, 09:45:35 pm »
What about instead of storing the ores themselves in the map data, simply storing a 1-bit dirt or no dirt map? Then, you have a function that determines what's there based on a formula. (row * column * seed value, truncated to 256, where 0x10, 0x20, 0x30, 0x40 etc. are ores, and everything else is dirt, for example)
in other words, the map never changes, but you don't need to store 16 tiles for 14 ores, air, dirt.
281
« on: August 16, 2013, 09:17:09 pm »
We're currently discussing using a parallax propeller to handle various I/O tasks, including hardware-generated VGA/Composite video. While the propeller works on handling the various I/O devices like the SD card, keyboard, video, audio, etc., the ez8 has plenty of time to run user programs.
282
« on: August 14, 2013, 11:03:03 pm »
Well, there's always the ability to treat any part of RAM like an accumulator register. That's very handy in the ez8.
283
« on: July 30, 2013, 12:00:53 am »
Today I half-finished an opcode reference for the ez8. It's on Keoni's site, right here. http://8times8.host56.com/ez8tut/reference/Opcodes.phpI'm planning on adding another part to it detailing the exact effects of every opcode by its hex value, but for now that should do.
284
« on: July 29, 2013, 11:58:49 pm »
It probably has a microcontroller in the unit doing all the sound handling, and simply passes the OS output from the calculator using a simple text protocol. I doubt the calculator does ANY of the sound processing.
Text to Speech is pretty easy when all the variables are either single letters or fixed words. "String One" for example, would be the clip "String" and share the word "One" with 1. GDB1 is even easier, sharing "G", "D", "B" and "1". By simply sending the token, the calculator tells the Plugin-Thing to say these fairly long, preprogrammed phrases. It would be easier, faster, and simpler than the alternative of this just being a fancy sound card.
Also, I bet it uses the USB for communication, with a standard hub. Since the extra is removable, communication between calculators isn't really an issue, so I doubt the micro-usb port supports it at all. At the very least, it doesn't need to support it.
285
« on: July 20, 2013, 08:31:42 am »
As long as HP is civil about programming support, hacking may not be required.
Pages: 1 ... 17 18 [19] 20 21 ... 208
|
Show Posts