GreaseMonkey

# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x2abb37ec, pid=1852, tid=2888 # # JRE version: Javaâ„¢ SE Runtime Environment (7.0_67-b01) (build 1.7.0_67-b01) # Java VM: Java HotSpotâ„¢ Client VM (24.65-b04 mixed mode windows-x86 ) # Problematic frame: # C [atioglxx.dll+0x437ec] Update your graphics drivers.While we're at it: # An error report file with more information is saved as: # C:\Users\Space Man\AppData\Roaming\.minecraft\hs_err_pid1852.log Paste that file here.

1. State the exact OC version you have. You can get this from the filename of the OC jar. 2. Post the crash log here. There WILL be a crash log SOMEWHERE.

This is something that I'm scratching my head over. It would be great if this were written in C (and if I had a dollar for every time I thought that... I think I'm up to about $5 now?), but alas, it isn't, and thus multiple return values are very much out of the question. Having a think about it, it would make sense if the bus ran at 1MHz. The Z80 currently runs at 2MHz, and all memory accesses on the Z80 tend to take a minimum of 3 cycles (in reality it's more like 2 cycles followed by a DRAM refresh but we'll just skip on that and assume the whole window is available for it). The MIPS3 core

Just went back to reading this and I forgot that I ever read it. > The text parsing required is also fairly simple, even on an 8-bit architecture like the 6502. ...converting decimal strings to integers is pretty difficult on a 6502, actually. I get the feeling it would be better to have a text string for architectures which handle text strings well, which then ends in a \n (10, 0x0A) and a \x00 (0, 0x00). Following that should be a binary format. Or heck, this would be better: BOOT:Lua 5.2,Lua 5.3:512+1199\n BOOT:MikeKaraoke:64+102\n \x00(pad up to next 16-byte boundary w/ \x00 b

I've used that colour test pattern before, it's an oldie but a goodie. If you want to have some seriously good fun with it, try writing a raymarcher. I did that prior to BTM16 (not 16.2, just 16) and had something really good but it appears it got lost after the great chunk corruption incident.

Going to quickly mention that there's two versions of DFPWM now (original DFPWM and DFPWM1a). If it sounds too slow, you have an old version of the mod (in that case it's using original DFPWM) and the tape is using DFPWM1a. If it sounds too fast, the mod is using DFPWM1a and the tape is using original DFPWM. Main reason 1a exists is because after a bit of component tweaking I managed to get it to sound *much* better than it used to. (It tends to beat MP3 at 48kbps now.) But yeah, what Lizzy said.

The problem: event.pull returns multiple arguments, not a table with the names put into it. So "touch" will actually contain touch[2], touch[3] instead of touch.x, touch.y. Step 1: Tidy up your places table: local places = {} places.station = {x = 218, y = 151, z = 60} places.library = {x = 205, y = 112, z = 59} places.roomComputer = {x = 206, y = 106, z = 71} places.docks = {x = 218, y = 104, z = 77} places.roomWarLeft = {x = 221, y = 99, z = 70} places.roomWarRight = {x = 221, y = 99, z = 79} places.emergency = {x = 227, y = 99, z = 79} places.proje

Disclaimer: Ubuntu still won't work.

Draft 1 D1: 2016-08-05T02:45:39+00:00 $ date -u -Iseconds ----There are two address spaces for all components: the config space, and the main I/O space. Every component has a VID (virtual ID) and that is how components are addressed. Every VID should be physically settable to any 8-bit value on each component. Any component with a VID set to 0xFF is rendered inaccessible by any methods that address by VID. Every component also has a PID (physical ID) which indicates the physical location of this component on a given bus master. The config space is read-only. Everything in the confi

Are you checking the files in-game or outside of it? You should be doing the former and not the latter. Do you have enough space on your disk to actually do this? You may have success if you do file:flush() before doing file:close(), but if that's what it takes to make it actually appear on disk, then that is probably a bug.

First things first, I'll clean up what you have: --create fake testing data local testDensity = {} local j = 0 for i=1,255 do testDensity[i] = j if j > 2 then j = 0 else j = j + 1 end end --opens test binary file local file = io.open("testBinaryFile", "wb") for i=1, 255 do local d = testDensity[i] file:write(string.char(d)) end file:close() I'm not sure if io.close(file) is properly supported - it's a bit cleaner to just use file:close().Does that code work? I mean you still have one byte per value instead of 2 bits per value, but does it write data to the file now? In order

My understanding is that this forum is mostly for putting proposed standards and whatnot but it should be fine for fleshing out ideas for standards. The problem with this approach of course is you're basically sending a password in the clear. But having a standard protocol + port would be nice. I'd personally do away with the username+password scheme and instead just check if the sender is on a list of authorised IDs. Having session logic should not be necessary as if something needs to be returned over the modem, it should be embedded into the code to run. At this point you'd probably

First things first, I assume you're selling it for in-game currency and not real money? With that said, you could do some form of Software as a Service thing in-game - all the robots are actually dumb slaves and the logic is handled by a master server. But the easiest solution is to use the robot's component address as an encraption key.

http://ci.cil.li/ may be of more use if you just want builds.

Currently unreleased. I would have to diff against a stock 4.1.13 kernel tree and that's more effort than I'm willing to put into it right now.