Sonic and Sega Retro Message Board: Andlabs - Viewing Profile - Sonic and Sega Retro Message Board

Jump to content

Hey there, Guest!  (Log In · Register) Help
Loading News Feed...
 

Andlabs's Photo
Group:
Wiki Sysop: Wiki Sysops
Active Posts:
2078 (1.15 per day)
Most Active In:
General Sega Discussion (447 posts)
Joined:
11-July 08
Profile Views:
1624
Last Active:
User is offline 17 minutes ago
Currently:
Offline

My Information

Member Title:
「いっきまーす」
Age:
20 years old
Birthday:
August 15, 1992
Gender:
Male Male

Contact Information

E-mail:
Click here to e-mail me
AIM:
AIM  pietro953
Website:
Website  http://

Previous Fields

Project:
Writing my own MD/Genesis sound driver :D
National Flag:
us
Wiki edits:
7,061

Latest Visitors

  1. Recent Status Updates
  2. About Me
  3. Topics
  4. Posts

Posts I've Made

  1. In Topic: My computer has been getting incrementally slower

    07 June 2013 - 01:16 PM

    I 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.

  2. In Topic: My computer has been getting incrementally slower

    06 June 2013 - 02:37 PM

    Resurrecting.

    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.

  3. In Topic: The Supreme Topic of 'Other' Knowledge.

    06 June 2013 - 12:15 AM

    http://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...)

  4. In Topic: Questions about transistor-level microchip logic

    05 June 2013 - 08:52 PM

    New 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

  5. In Topic: Questions about transistor-level microchip logic

    01 June 2013 - 04:57 PM

    Sorry 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.