Previous Page | Next Page
- by hcs at 9:21 PM EDT on June 15, 2005
- Found the source of the unreliability (apparently I didn't understand structs as well as I thought) but the crashes still perplex me.
I have the problem down to cause and effect: if I don't fill the frame buffer before I call my controller reading function (in a continuous loop so it updates) the program eventually crashes. This makes no sense to me, however, as all the frame buffer filling function does it write a bunch of data, uncached, directly to RAM. If it was cached writes there might be something to it, like maybe something gets written back when the cache is full, but there isn't any uncache to speak of to write back... it's really got me up a wall.
- by hcs at 11:39 PM EDT on June 15, 2005
- New version up, now with a build script that pratically runs itself.
Basic controller reading support joins video support. The demo displays controller status (plugged in or not, x and y axis, buttons) and some profiling info I pull from the COP0 count register.
The sine wave is controlled by the controller 1 joystick. Pressing start on controller 1 makes the background red.
Be advised I haven't found the cause of the bug which causes controller_Read() to crash when it is called before VI_FillScreen(), so if you want to write anything at this point do a VI_FillScreen() to black first.
- by hcs at 11:40 PM EDT on June 15, 2005
- forgot the link:
n64test7.zip
I'm considering moving the development of this library to sourceforge so it won't be able to fall off the net and I can maybe get some help.
- corrected link by hcs at 11:41 PM EDT on June 15, 2005
- n64test7.zip
'bout time I added an editing feature, isn't it...
- by hcs at 8:56 PM EDT on June 16, 2005
- As you may or may not know, there are two checksumming systems on the N64, one is built into the system in the form of the elusive PIF boot ROM, which the CPU actually runs before even looking at the cartridge, the other is in the 0x1000 byte header in front of a ROM that calculates the checksum of the first 0x100000 bytes of the ROM (after the header, that is), and sets things up. While the latter (CRC within the header) is thoroughly understood the PIF checksum algorithm is currently unknown.
I'd like to write N64 programs without having to rely on headers pulled from existing games, thus I want to write my own header. The problem is that the header is checked by the unknown boot ROM checksumming algorithm. It is therefore my intention to understand the checksum well enough to allow use of my own code. Then I can release the source code to a library which represents the whole ROM, without an illegally copied bit at the beginning.
I've been informed by people in the N64 scene longer than me that this has been attempted but never completed, and CRC algorithms aren't exactly my strong point, but I'm going to see what I can do.
- by hcs at 10:31 PM EDT on June 23, 2005
- The checksum routine is rather straightforward (though I'd certainly never call it simple), I've recoded it in C here (why is the extension asm? er, whoops)
The result is then fed to some undocumented registers which I presume map to the CIC chip, so it has the final say in checking. I should be able to spoof this by providing a known checksum value. Haven't been able to test yet, though.
- by hcs at 9:13 AM EDT on July 5, 2005
- Note to self (and anyone else interested):
It is very important to invalidate the instruction cache if you're writing instructions somewhere that you actually want executed (like, say, an exception handler).
Cache instruction 0x10 does this. The appropriate line in GNU asm is:
cache 0x10,($9)
or in U64ASM:
cache $10,(t1)
- by hcs at 8:26 AM EDT on July 7, 2005
- I took some time off from trying to figure out the boot situation and finally disassebled an N64 Game Shark uploader. I've now got a Windows XP-compatible command line uploader, which I currently have set up to take an NES ROM on the command line and send it with Neon64. Cool stuff. Now I'm working on figuring out the reading bits so I can detect the ROM version (US, Europe, and maybe I'll get around to implementing support for the Japanese version now) and avoid reuploading the emulator itself if it's already running.
It'll be open source, of course, which will make it the only open source GS uploader I know of.
- by hcs at 12:35 PM EDT on July 7, 2005
- No detection yet, reading is a bit confusing...
Here's the uploader, which includes Neon64.
- by hcs at 12:56 PM EDT on July 7, 2005
- Now this is odd, the uploader works well in Windows XP but not in Win98 or in a direct port to Linux. Maybe the inpout32 driver is doing something special with the data when it's actually handling it under XP.
Previous Page | Next Page
Go to Page 0 1 2 3
Search this thread
Show all threads
Reply to this thread:
HCS Forum Index
Halley's Comet Software
forum source