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 ... 25 26 [27] 28 29 ... 208
391
« on: April 03, 2013, 01:13:39 pm »
OH  Those should be += or |= defines after the first one. But yes, that's the idea.
392
« on: April 03, 2013, 10:03:31 am »
Nope. The CX doesn't have the emulator, so I'm not sure if that's still the case.
393
« on: April 03, 2013, 09:53:48 am »
Here we go! Can't test it myself, as I don't have the screen. Try it out! #include <T6963.h>
#include <T6963_Commands.h>
#define CLK 13
#define DAT 12
T6963 lcd(240,128,6);
void setup() {
lcd.Initialize();
lcd.clearCG(); // Clear character generator area
lcd.clearGraphic(); // Clear graphic area
lcd.clearText();
pinMode(CLK,INPUT);
pinMode(DAT,INPUT);
}
void loop() {
for (byte y = 0; y < 128; y +=2){
for (byte x = 0; x < 192; x+=16){
for (byte b = 0; b < 8; b++){
//Grab a byte of pixels. Ideally you would alter the axe side to make this a single read.
while (!digitalRead(CLK));{
byte c;
c = digitalRead(DAT);
c << 1; // shifts the pixel to the next slot.
//The necessary clock delay
while (digitalRead(CLK));
delayMicroseconds(1); //Needed for a stable connection, you could also use some asm("nop");
}
}
//This scales it to 2 bytes.
byte write0 = (c & 0b10000000);
byte write0 = (c & 0b10000000) >> 1;
byte write0 = (c & 0b01000000);
byte write0 = (c & 0b01000000) >> 1;
byte write0 = (c & 0b00100000);
byte write0 = (c & 0b00100000) >> 1;
byte write0 = (c & 0b00010000);
byte write0 = (c & 0b00010000) >> 1;
byte write1 = (c & 0b00001000);
byte write1 = (c & 0b00001000) >> 1;
byte write1 = (c & 0b00000100);
byte write1 = (c & 0b00000100) >> 1;
byte write1 = (c & 0b00000010);
byte write1 = (c & 0b00000010) >> 1;
byte write1 = (c & 0b00000001);
byte write1 = (c & 0b00000001) >> 1;
//This section writes all the bytes, hopefully in the right places.
lcd.GraphicGoTo(x,y);
lcd.WriteData(write0);
lcd.GraphicGoTo(x,y+1);
lcd.WriteData(write0);
lcd.GraphicGoTo(x+8,y);
lcd.WriteData(write1);
lcd.GraphicGoTo(x+8,y+1);
lcd.WriteData(write1);
//lcd.setPixel(x,y,c);
//lcd.setPixel(x+1,y,c);
//lcd.setPixel(x+1,y+1,c);
//lcd.setPixel(x,y+1,c);
}
}
}
394
« on: April 03, 2013, 09:45:22 am »
I'm working on a modification that reads and writes bytes at a time. It should also be easy to make your axe code give bytes instead as well.
395
« on: April 03, 2013, 08:26:39 am »
Not all action games need smooth scrolling, though. You could make a pretty decent platformer on one screen if you were willing to go for a smaller character.
What kind of LCD controller does the CSE use, anyway? I'm curious now.
396
« on: April 03, 2013, 08:05:20 am »
Do I not get to see code? :'(
Also, if you use the softwareserial library, you can free up port D for pin usage.
397
« on: April 03, 2013, 07:53:07 am »
I keep thinking I should update from 2.30, but I never see any good reasons to, aside from a few zstart/omnicalc features dying. (Like zStart's MAIN feature )
398
« on: April 03, 2013, 07:43:58 am »
You should post your code. I'd love to poke around for optimizations!
What arduino are you working with, anyway? From the sound of it it's an older one, with an atmega168. You can actually buy preprogrammed drop in replacements that have double the RAM.
Although, I might be able to work enough variables into the Flash program rather than RAM, so you could actually fit the screen.
399
« on: April 03, 2013, 07:43:01 am »
Nope, in fact that is pretty much the whole reason the nonCAS and CAS nspire OS differ in size. The ROM is nearly exactly the size of the difference.
400
« on: April 01, 2013, 07:57:13 pm »
BTW, not sure if it was clarified, but aeTIos, the 84+ pad is just a keypad. It has certain wires shorted to ground rather than vcc so the calc can tell which one it is. It doesn't store the OS.
It does have a few bits for debouncing the link port, but nothing as big as a flash chip. The keypad port is just raw I/O for the most part.
401
« on: March 20, 2013, 09:40:10 pm »
I would bet most of that is simply the different controllers involved. Also, gbc4nspire should have far greater compatibility than gpSP or nespire. The GB and GBC have way less in the way of specialized hardware. (NES has mappers, GBA is special )
402
« on: March 20, 2013, 08:37:06 pm »
Well, it has all the original levels, same game physics, etc, but it's definitely different. The game itself is far closer than the SNES All-Stars pack, for example, but it has a lot of extras. It was called Super Mario Bros. Deluxe. Here's a video. Don't get turned away by the menus. The game is really similar to the original. It even has the Super mario bros 2 levels unlockable (The good SMB2, not the crappy one with peach)
403
« on: March 20, 2013, 08:17:39 pm »
I mentioned that in my post, I believe. Still, though, the GBC version is better.
404
« on: March 20, 2013, 05:20:30 pm »
That's true. The micro excluded the hardware for "GBC Mode" and replaced it with other, presumably cheaper DSPs.
The backwards-compatibility hardware is generally used for side tasks. For example, IIRC the DS uses the GBA's ARM7 processor to handle the touchscreen and sound. However, since this programming was part of the BIOS and not the games, it can be redesigned to use other hardware for the same purpose.
405
« on: March 20, 2013, 02:45:19 am »
Yeah. Fire Emblem via gpSP, the other two by gbcnspire. (Unless you want the NES version, but SMB deluxe for GBC is better)
Pages: 1 ... 25 26 [27] 28 29 ... 208
|
Show Posts