- Wiki Sysop: Wiki Sysops
- Active Posts:
- 2078 (1.15 per day)
- Most Active In:
- General Sega Discussion (447 posts)
- 11-July 08
- Profile Views:
- Last Active:
- 17 minutes ago
- Member Title:
- 20 years old
- August 15, 1992
- Writing my own MD/Genesis sound driver :D
- National Flag:
- Wiki edits:
Posts I've Made
07 June 2013 - 01:16 PMI can run memtest86 later; here's free -m output:
total used free shared buffers cached Mem: 3943 3614 329 0 151 1153 -/+ buffers/cache: 2309 1633 Swap: 4082 595 3487
However I think the CPU performance thing showed me what happens: the CPU is throttled to 1.6Ghz due to overheating, and will do this even if I force the CPU to run at max frequency (set userspace governor and force a frequency). GerbilSoft suggested cleaning and reapplying thermal paste between the CPU and heatsink. I won't be able to do that for at least a few days, so until then, thanks again.
06 June 2013 - 02:37 PMResurrecting.
No there is no virus issue because I'm on Linux; no it's not Firefox because the slowdown happens even when Firefox is not running. I verify all my ROMs against both no-intro and MAME anyway (and have written programs to do so).
I just tried dusting the fans with compressed air again, again to no avail.
This is now affecting all emulators, music making programs (or at least just FamiTracker, maybe also MilkyTracker but the effect is more subtle), and IDA.
What are my next troubleshooting steps? Thanks.
06 June 2013 - 12:15 AMhttp://jul.rustedlog...d=422575#422575 Ugh, looks like our Sonic Spinball prototype ROM is a bad dump :| (I'm sure because LocalH posted this that it is old news, bu the information does not seem to have reached ROM sets yet. And yes I know the dump may seem cool because of what it has, but if we can get the originals of both that would be nice too...)
05 June 2013 - 08:52 PMNew hypothesis: is it possible that my monitor code is just too slow? That is, must I guarantee that everything my external devices do will always run between master clock ticks? Since the only thing that would cause the deadlock of the chip sending a clk1 and the monitor sending to the data bus at the same time would be if a clk0 tick happened while in the middle of the monitor code loop. If so I'm not entirely sure what will happen when I expand this to cover other devices...
I also got this suggestion from #go-nuts; not sure if it would help
Quote[19:39] <|Craig|> pietro10: I'd think a bool would be a better model of a pin than a channel. Maybe you could let things subscribe to get notified of changes (or maybe just rising or falling edges) via channels, but thats one channel per subscriber, not one channel per pin
01 June 2013 - 04:57 PMSorry for the quick double post but I'm still b it confused now: I'm now occasionally winding up in a situation where my monitor is trying to send data but the emulator thread is trying to pulse clk1. I immediately see two possibilities: either the monitor is too slow or I'm not pulling rdy at the right time... as this is all after REF "B". I had the clocks sending on demand (chiploop() in the second link) but that just caused everything to hang up for some reason; now it sends the clock pulse as soon as the node is changed... unless I should change it back and see what's wrong. Any ideas? Thanks.