Back
[00:00:20] <Roklobsta> ah, does -Wall turn it on?
[00:03:18] <Roklobsta> fo you mean -Wformat?
[00:05:10] <Roklobsta> cppcheck found an error: _spcr |= _BV(SPR1) | _BV(SPR1); both sides of the | are the same.
[00:05:20] <Roklobsta> a typo like that could drive you nuts
[00:05:27] <Roklobsta> for an hour or so
[00:06:19] <Roklobsta> or worse
[00:11:55] <Xark> Roklobsta: Yes. People who suppress warnings in C/C++ do themselves no favors IMHO. :)
[00:12:42] <Xark> I always crank them up to the max and then just disable a few specific "silly" ones (after making sure they don't apply to the project).
[05:29:06] <megal0maniac> RikusW: Hey. Quick question. I'm struggling to install the U2S drier on XP x86...
[05:29:13] <megal0maniac> Doesn't like the inf file on your site
[05:29:39] <RikusW> ooh
[05:29:49] <RikusW> works fine on my XP x86
[05:30:04] <RikusW> there is two inf files on the site, try the other one ?
[05:30:14] <megal0maniac> The other one is for x64 though
[05:30:37] <RikusW> the x64 one should work on x86
[05:30:44] <RikusW> its for both x64 and x86
[05:31:01] <RikusW> iirc I used the x64 on XP
[05:32:21] <RikusW> check that the device ID is ok, and choose "select file"
[05:32:37] <RikusW> (when installing or upgrading the driver)
[05:33:09] <megal0maniac> "The selected file does not contain any information about your device"
[05:33:13] <RikusW> XP will complain its not signed, but its only the inf, so its safe to ignore that
[05:35:06] <megal0maniac> Ah. The VID/PID was completely different
[05:35:24] <megal0maniac> Seems to be different between the two U2S boards...
[05:35:48] <RikusW> you're sure its not the AVRISP mkii fw ?
[05:36:27] <RikusW> or some other LUFA fw you loaded ?
[05:36:49] <RikusW> in bootloader mode it should work
[05:36:53] <megal0maniac> Nope, it's the new one you sent
[05:37:02] <RikusW> (arduino CDC maybe ?)
[05:37:18] <RikusW> did it work before ?
[05:37:35] <megal0maniac> Don't think I've tried it :)
[05:37:48] <RikusW> try in Linux ?
[05:38:01] <megal0maniac> It's working now
[05:38:08] <RikusW> what was wrong ?
[05:38:21] <megal0maniac> Sorry, wasn't very clear about it :) Just changed the VID PID in the inf file
[05:38:40] <RikusW> very weird...
[05:39:17] <RikusW> I certainly didn't change it
[05:40:45] <megal0maniac> Oooh!
[05:40:54] <megal0maniac> It wasn't the new one, it was my one
[05:41:10] <megal0maniac> Running an Arduino sketch
[05:41:19] <megal0maniac> My bad
[05:41:50] <megal0maniac> Except that shouldn't have mattered for bootloader mode :/
[05:41:57] <RikusW> heh
[05:42:02] * megal0maniac shrugs
[05:42:41] <RikusW> was it really boot mode or maybe you mistaken it for app mode ?
[05:42:54] <RikusW> the led flash once for both....
[05:45:05] <megal0maniac> Who knows. Well it's working now :)
[05:45:26] <RikusW> good
[05:45:36] <RikusW> </tech support> :-P
[05:53:26] <megal0maniac> :P
[05:53:51] <megal0maniac> A friend and I are attempting to get nrf24l01s to talk to one another
[05:54:06] <RikusW> I have 4 of them too
[05:54:09] <megal0maniac> What is reset on the ISP header connected to?
[05:54:10] <RikusW> not used it yet
[05:54:21] <RikusW> on U2S ?
[05:54:24] <RikusW> B0
[05:54:43] <RikusW> unless you change the jumper then it is connected to reset on the 32u2
[05:55:57] <megal0maniac> Ah of course :/
[05:56:01] <megal0maniac> Sorry, stupid question
[05:56:08] <RikusW> no problem ;)
[05:56:36] <RikusW> you have the pcb pics too, should only take a little time to see where the tracks go
[05:59:21] <RikusW> www.irf.com/product-info/datasheets/data/pvi5013r.pdf
[05:59:27] <RikusW> looks like a nice to have part
[06:04:57] <megal0maniac> This is going to be challenging. Haven't used SPI before :/ I apologise in advance for all the questions :)
[06:06:14] <RikusW> spi isn't that hard, about the same as using serial
[06:06:40] <megal0maniac> Yeah, but I haven't done either one successfully
[06:06:42] <RikusW> the main difference is that the slave cannot transmit until the master transmits
[06:07:31] <RikusW> so it you send one byte and expect a one byte reply you'll have to send two bytes to get the reply
[06:07:34] <RikusW> *if
[06:08:19] <RikusW> look at it like a 8 bit shift register in both chips connected using miso/mosi
[06:08:41] <RikusW> they exchange data each time the master transmits a byte
[06:11:19] <megal0maniac> Makes sense..
[06:12:22] <RikusW> just send you some sample code I used to make SPI work
[06:12:26] <RikusW> *sent
[06:12:55] <RikusW> on your domain email
[06:13:37] <RikusW> basically it connects the SPI port to the U2S COM port
[06:13:55] <RikusW> so then you can easily debug the protocol from the PC and don't have to upload fw each time
[06:14:43] <RikusW> megal0maniac: iirc I used B5 as interrupt pin to make the U2S fetch SPI data
[06:14:54] <RikusW> from the slave
[06:15:37] <RikusW> you might want to make it transmit everything back to the pc instead
[06:15:58] <megal0maniac> Ah, cool :) Thanks
[06:16:13] <RikusW> its working and tested code :)
[06:16:41] <RikusW> it shows just how simple it is to use the U2S CDC code
[06:21:59] <RikusW> put it on my site too
[06:22:17] <megal0maniac> CLKPR seems to be making no difference :/
[06:22:36] <RikusW> are you assigning it yourself ?
[06:23:05] <RikusW> use the provided set_clock() function
[06:23:37] <RikusW> usb_lib.h
[06:34:36] <RikusW> megal0maniac: for a start I'd suggest you use a lowish SPI clock
[06:34:56] <RikusW> get it working first and then increase the clock
[06:35:27] <RikusW> too high SPI clocks are known to cause trouble
[06:54:01] <RikusW> http://www.theregister.co.uk/2013/07/15/linux_for_workgroups/
[08:21:24] <inflex> zSwap should be an interesting experiment
[09:00:22] <megal0maniac> RikusW: All my delays are double the expected length. Is there a prescaler set by default?
[09:01:40] <inflex> usually /8
[09:07:12] <inflex> no chance you're failing to account for the function call/close or interrupt cycles?
[09:09:13] <Valen> inflex: zswap costs more than ram ;->
[09:10:22] <inflex> ja, but given that when you start swapping to HDD you end up waiting millions of cycles
[09:10:38] <Valen> the moral of the story i meant was don't swap ;->
[09:11:00] <inflex> I remember fondly the old days where having compressed binaries resulted in faster start up times, of course, we're talking in 20MB HDD days
[09:11:03] <Valen> does zswap write compressed data back to the disk at all? I can see it talking about doing it into ram
[09:11:09] <Valen> thats coming back btw
[09:11:19] <Valen> zfs with compression on can result in faster xfers
[09:11:23] <inflex> I would imagine just in RAM, going to the HDD would be pointless
[09:11:44] <Valen> I was thinking about that, compressing it on the way to the hdd would speed it up
[09:11:56] <Valen> though it depends on how much you are swapping out
[09:12:01] <Valen> if its a 4kb page, then no
[09:12:10] <Valen> if its a huge block I can see upsides
[09:12:40] <inflex> Still, should be interesting to see how it pans out in the real world
[09:13:15] <inflex> certainly CPUs are amply fast enough to do it, hell you could probably get the GPU in the act
[09:14:22] <inflex> I wonder if they invoke some sort of tagging so that it doesn't bother to compress pages that are known to contain already compressed data
[09:14:28] <Valen> hmm, nah going across the bus would nerf the latency
[09:14:50] <Valen> using GPU ram for system ram was something you used to be able to do
[09:14:59] <Valen> I wonder if that'll make a comeback
[09:15:04] <inflex> but you're comparing HDD speeds to bus... it's 10:1 at least, closer to 1000:1
[09:15:09] <Valen> with 3Gb+ cards being common
[09:15:33] <Valen> I meant, transferring the data to the GPU then back wouldn't pay for itself timewise vs just doing it in the CPU
[09:15:44] <inflex> oh right right, sorry
[09:15:45] <Valen> I don't think GPU's would be very good at compression anyway
[09:16:40] <inflex> depends on what algorithm you go with; they might not be "good", but they could probably handle a 4K block in each core parallel loaded, so you'd get a nice MB or two compressed in a couple of cycles
[09:18:39] <Frigolit> depends on the GPU, but yes, they can do more stuff at the same time ofc. question is how much faster they can compress data without including overhead
[09:19:01] <Frigolit> DMA should help out with some of the overhead anyway, if it's possible to use DMA with OpenCL/CUDA
[09:19:08] <Valen> lzo can do compression at 410Mbyte/sec with one core of an I5 at 2.7ghz
[09:19:19] <Valen> http://code.google.com/p/lz4/
[09:19:23] <Frigolit> try lzma instead
[09:19:54] <Frigolit> doesn't lzo have horrible compression ratios compared to even gzip?
[09:20:51] <Valen> nfi
[09:21:10] <Valen> the big thing is compression parrallels very badly
[09:21:13] <Frigolit> but the first thing to consider is ofc that GPU cores will work better with blocks of data rather than constantly shoving data between GPU and the CPU or system RAM
[09:21:22] <Valen> if you have a stream of data that is
[09:21:51] <Frigolit> Valen: depends, there are techniques for that as well, which can however lower the compression ratio a bit depending on the amount of parallel blocks used though
[09:22:10] <Frigolit> with gzip for example you can split the data and use sync markers
[09:22:33] <Valen> which is fine if you have a huge block of data
[09:22:36] <Frigolit> pigz (parallel gzip) does this for example
[09:23:02] <Frigolit> yea, and as i said, using the GPU works best when they can crunch on data for a while, which doesn't exactly work with small amounts of data
[09:23:32] <Frigolit> but if you consider for example lzma which is a slower algorithm in general, the block size can be smaller because the crunch time is higher
[09:24:42] <megal0maniac_afk> zlog
[09:25:04] <Frigolit> it would for example be pointless to use it with a webserver compressing data on-the-fly or other network protocols compressing packets
[09:25:25] <Frigolit> but could potentially be useful when working with large files
[09:25:32] <Valen> actually I can see the webserver thing working
[09:25:50] <Valen> because you could pass umteen small chunks over to it
[09:25:51] <Frigolit> it would at least take load off the CPU
[09:26:10] <Frigolit> but potentially increase latency a bit
[09:26:26] <Valen> not going to bother a webserver overly much
[09:26:47] <Valen> if you really did it "right"
[09:27:14] <Frigolit> hehe, when you're at the size of twitter or facebook, even microseconds matter when it comes to how long a request is being processed, because it uses CPU time :)
[09:27:18] <Valen> pack up the file to be compressed, with a header, get the gpu to compress it and form it into packets ready to hit the wire
[09:27:30] <Valen> facebook won't be compressing much on the fly
[09:27:39] <Frigolit> nah, just saying
[09:28:02] <Frigolit> it would be a interesting experiment though
[09:28:26] <Valen> all we need is somebody to give us $3M to write up the study
[09:28:31] <Frigolit> indeed
[09:28:52] <Frigolit> and doing research at beaches in warm countries
[09:29:01] <Frigolit> etc
[09:29:46] <Valen> sounds good
[09:29:53] <Valen> don't forget the lab assistants
[09:30:20] <Frigolit> female ones i assume
[09:30:34] <Valen> of course
[09:30:38] <Frigolit> :)
[09:30:43] <Valen> question hardly bears asking
[09:30:48] <Frigolit> true
[09:31:13] <Frigolit> actually it would be nice to test after i've gotten better at OpenCL
[09:31:38] <Frigolit> i wanna use OpenCL/CUDA to accelerate some stuff for a project
[09:31:56] <Frigolit> but i gotta learn it properly first so i can do some benchmarks on that
[09:32:09] <Frigolit> afterwards, compression could be a nice thing to try
[09:47:22] <RikusW> megal0maniac_afk: 8MHz by default
[09:58:37] <megal0maniac_afk> Not going to bother with prescalers for this, 8mhz will be fine
[10:21:57] <RikusW> megal0maniac_afk: I'd just use U2S COM to SPI and develop most of the stuff on the PC
[10:26:11] <Duality> hi
[10:26:29] <Duality> got a pin toggeling at 143khz with a timer :)
[10:41:01] <Duality> hmm
[10:41:43] <Duality> i can get even higher values 0.o
[11:43:26] <braincracker> h
[12:20:35] <braincracker> h
[12:20:36] <braincracker> got another tft ;/ can't live with a monitor that has been abused
[12:20:36] <braincracker> thos hp tft monitor has menu option to turn off status led :P
[12:20:36] <braincracker> ;>>
[12:20:38] <braincracker> that is an alternative to sandpapering and hacking the led.
[12:20:38] <braincracker> i will put this feature in my things too, neat odea to switch it off from menu
[12:21:18] <inkjetunito> a nice feature indeed
[12:21:47] <braincracker> especially for us, night haxorz right?
[12:24:43] <inkjetunito> braincracker: well. a haxor could cover the led with a piece of tape
[12:24:57] <braincracker> but it is nice if you don't have to :)
[12:25:13] <braincracker> i even have aluminium tape btw
[13:34:53] <reaxion> Hi
[13:34:57] <reaxion> Is anyone around?
[13:39:31] <reaxion> I am trying to learn how logic gates and stuff work with the ATmega128. I'm examining a circuit that is using PE3 on the ATmega128, and it goes to some kind of SOT23-5 package, then two of the pins from the SOT23-5 connect to pins 4 and 5 of the quad logic gate (a 74HC132D quad logic gate 14-pin package)… Just trying to work out what the little SOT23-5 might be doing?
[13:39:58] <reaxion> The SOT23-5 is marked with the letters ACL it appears
[13:43:41] <reaxion> The 74HC132D is a Quad 2 input NAND gate
[13:44:39] <braincracker> with schmitt trigger
[13:45:12] <braincracker> i don't get the meaning of what you are doing but ok
[13:46:02] <reaxion> braincracker: Thanks for replying
[13:46:13] <reaxion> Yes, I am pretty new at all this
[13:46:29] <reaxion> and I got an atmega128 board from a friend, so I'm trying to work out how to program it
[13:46:54] <reaxion> but I'm not sure what this little 5 pin package is doing
[13:47:31] <reaxion> do you have any suggestions as to what sort of function it could perform? A timer maybe?
[13:47:41] <reaxion> It may be AC1 rather than ACL
[13:47:46] <reaxion> very small and hard to read
[13:49:29] <braincracker> i think it is an LDO regulator, i have some too
[13:49:50] <braincracker> that regulates VCC for the atmega
[13:50:31] <reaxion> I see. Would that require a logic gate to make it operate correctly?
[13:51:44] <braincracker> no.
[13:52:02] <braincracker> i just hook my atmega up to a lithium battery and works fine
[13:52:18] <reaxion> Hmm. I wonder why it's using a logic gate in that case
[13:52:31] <braincracker> maybe because of the schmitt trigger function
[13:52:52] <braincracker> but i don't feel like it is needed
[13:55:17] <reaxion> Hmm, okay...
[14:01:00] <reaxion> Thanks for your thoughts on that braincracker. I will continue to investigate
[14:05:55] <braincracker> you need a 100nf ceramic capacitor across vcc/avcc and gnd, and a +3-5V power source like a pc psu, an isp connector, and an isp programmer
[14:06:21] <braincracker> compile some blink code on gcc and burn with avrdude, done, it's alive
[14:06:44] <braincracker> simpler you ever thought
[14:06:47] <braincracker> than
[14:14:56] <xdarklight> evening guys
[14:15:08] <xdarklight> I have a quick question regarding an ATTiny85
[14:15:28] <xdarklight> according to it's datasheet it *does* have Timer1/Counter1
[14:16:44] <xdarklight> what I want is quite simple: I want it to count every time one of the pins goes HIGH or LOW
[14:17:28] <specing> one specific pin or all of them?
[14:18:23] <xdarklight> one specific pin
[14:18:30] <xdarklight> any one, except the T0 pin
[14:18:46] <specing> one might have a CTC mode or how is it called again
[14:19:00] <specing> havent done avrs in over a year
[14:21:11] <xdarklight> ok, thanks - I guess I have to dig deeper into the datasheet
[14:22:31] <braincracker> you can't do anything else
[14:28:20] <BJfreeman> xdarklight counts don't count events but count at a specific rate then create a inteript
[14:29:11] <BJfreeman> what yiu want is a interupt then the interupt service you increment a value
[14:29:34] <xdarklight> BJfreeman: well, I may have explained what I want not quite correct, sorry
[14:29:47] <xdarklight> I have a 7555 timer circuit which does capacitive sensing
[14:30:20] <xdarklight> I want to measure the output of the 7555 circuit (= frequency) - which can be done best using a timer/counter
[14:30:33] <braincracker> i'd skip the 555 part
[14:30:38] <braincracker> but ok
[14:32:35] <BJfreeman> xdarklight yes,, that is done with and interupt, now you can use the timer to see how may counts you did in a period (frequency)
[14:37:56] <xdarklight> BJfreeman: hmm, ok
[14:38:05] <xdarklight> one more thing after digging around in the various datasheets
[14:38:14] <xdarklight> what I want is called "External clock source" for the timer/counter
[14:38:23] <xdarklight> and this is only supported by T0
[14:38:36] <xdarklight> ATMega supports it on T1 as well, but not the ATTiny seriees
[14:40:52] <BJfreeman> external clock source refers to a Resonator or Crystal that sets the Cpu Clock cycles throut the prescalers
[14:41:12] <xdarklight> not in case of the TCCR1B register
[14:41:17] <BJfreeman> through
[14:44:36] <BJfreeman> I am looking at the datasheet 12.8.2 Timer/Counter Control Register B – TCCR0B
[14:44:58] <BJfreeman> I don't see a TCCR1B
[14:45:29] <xdarklight> ah yes, because I took TCCR1B from an ATmega368 datasheet
[14:46:29] <xdarklight> have a look at Table 11-6 in the attiny85 datasheet
[14:46:50] <xdarklight> the last two entries are what I'm looking for, except I wanted those for timer/counter1 (table 11-6 is for timer/counter0 though)
[14:47:16] <BJfreeman> hmmm must have differnt 85 data sheets
[14:47:55] <BJfreeman> 11.4 Pin Change Mask Register – PCMSK is the highest I go
[14:49:12] <xdarklight> page 80 here, "Table 11-6 Clock Select Bit Description"
[14:51:53] <BJfreeman> page 80 Figure 13-2. Prescaler for Timer/Counter0
[14:53:28] <BJfreeman> 7598I–AVR–10/12
[15:01:08] * Xark ends up downloading the same ones over and over (can never remember docXXXX.pdf random numbers). He has now at least taken to renaming some of the more popular ones for easy reference. :)
[15:06:16] <BJfreeman> Xark I keep the doc title then append what I can find it uder
[15:06:44] <BJfreeman> under
[15:07:14] <Xark> BJfreeman: Yes, that is what I have taken (to try to remember) to do (perhaps on your or another freenode members suggestion).
[15:07:44] <Xark> It was getting silly when I had like (7) after my 328 doc. :)
[15:08:01] <BJfreeman> LOL
[15:08:47] <BJfreeman> I don't keep track of who I have said it to :P
[16:13:09] <WhaleBoobs> are microcontroller prices going down? like are they being developed at the same speed as CPU's?
[16:13:36] <WhaleBoobs> do they follor moores law i mean :P
[16:14:23] <Xark> WhaleBoobs: I think the cheapest ones aren't getting a lot cheaper. However, overall they are becoming for powerful (e.g. 32-bit MCUs encroaching on 8-bit MCU costs).
[16:14:32] <Xark> more powerful*
[16:14:39] <Roklobsta> moar betta
[16:17:44] <Toneloc> yeah, 8-bit mcu are deliberately getting squeezed out by manufacturers
[16:17:51] <Toneloc> in favour of 32-bit
[16:18:06] <Toneloc> because the silicon cost is essentially the same
[16:18:24] <Toneloc> and the issue is also taht 8-bit mcu use older processes
[16:18:35] <Toneloc> which aren't compatiable with the 32-bit devices
[16:19:06] <Toneloc> and hence you would need to run two processes- one for a device who's market is not growing- the 8-bit mcu
[16:19:13] <braincracker> this sounds stupid i think.
[16:19:31] <braincracker> and i use 32 bit counters in my 8 bit MCU
[16:19:31] <Toneloc> so, many mcu manufacturers have sold of the 8-bit lines
[16:19:42] <Toneloc> to other companies who still run the old processes
[16:19:57] <braincracker> so what do you sell?
[16:20:00] <Xark> braincracker: Yeah, but now the chip that reads a door sensor and lights an LED can talk TCP/IP too. :)
[16:20:00] <Roklobsta> well, pic and avr won't go anywhere
[16:20:02] <Toneloc> and let them wring every last ounce of profit out of the market
[16:20:09] <Roklobsta> do the 32bittters have the same low power use?
[16:20:29] <Toneloc> and lets them concentrate on the 32-bit market
[16:20:43] <braincracker> Toneloc<= ok, go on, what you sellin?
[16:20:58] <braincracker> anything better than atxmega, or the new atmel arms ?
[16:21:15] <Xark> braincracker: You could try AVR32. :)
[16:21:24] <braincracker> i'm not into that
[16:21:26] <Toneloc> braincracker, nothing, i just like to keep my ear to the ground- I'm into stocks.
[16:21:27] <braincracker> rather the atmel arm
[16:21:46] <Xark> braincracker:
http://www.aery32.com/ Yes, or ARM.
[16:22:29] <braincracker> http://www.atmel.com/products/microcontrollers/arm/default.aspx
[16:22:31] <Roklobsta> Finland. Oh forget it
[16:23:02] <braincracker> nobody forces you to use 8 bit atmels for flashing leds, you can use a 100MHz arm too
[16:23:16] <Xark> Roklobsta: Hehe, hey the Aery32 folks are very nice. :)
[16:23:44] <BJfreeman> heard that the ARM is targeted for 3ghz in 2014
[16:23:59] <Toneloc> well, really if 32-bit devices costs less, why would you use an 8-bit device?
[16:24:03] <braincracker> maybe, but they should keep the power low.
[16:24:09] <Toneloc> say power consumption was equal
[16:24:18] <braincracker> it is not.
[16:24:55] <braincracker> but hese arms have nice power save features too
[16:25:41] <BJfreeman> nat all m3 are equal
[16:26:41] <Roklobsta> AVR is simple to get your head around
[16:26:53] <BJfreeman> when label ARM they have components provided by ARM.com but can have less or more featires
[16:27:03] <Roklobsta> which makes it so nice
[16:27:36] <BJfreeman> I find the AVR is good for subsystem control
[16:28:30] <Xark> Yeah, ARM is no doubt more powerful, but all the different vendor versions have made the architecture a bit of a "mess". They are trying to come up with common APIs etc. now because of this issue.
[16:28:55] <Xark> (different instruction modes too - third time is the charm...)
[16:37:04] <BJfreeman> the only thing that bugs me is vendors supply a pin count less than the features and the two features I want are on the same pin
[16:37:45] <BJfreeman> why can't they just provide the 178 pings
[16:37:51] <BJfreeman> pins
[16:37:52] <Xark> BJfreeman: Yeah, I can see that being frustrating. I guess you have to study the specific datasheet carefully.
[16:38:01] <Xark> Heh
[16:39:12] <BJfreeman> took me a while to find a supplier that uses the 178 pin chip
[16:55:57] <twnqx> 3ghz arms will eat as much power as PC chips at that clock :P
[17:04:52] <BJfreeman> probably
[17:05:01] <specing> yeah
[17:05:31] <specing> a bit less though
[17:06:03] <twnqx> not much.. if course they'll need fewer transistor, but at that clock rate switching losses dominitae
[17:06:07] <specing> but imho 3 GHz is just insane
[17:06:09] <BJfreeman> depends on features like DAC, Camera interface, FSM
[17:06:21] <twnqx> dunno, i run my haswell 4ghz
[17:06:31] <twnqx> and i could use more oomph
[17:06:41] <specing> why can't we just write threaded software and have 100 1GHz cores?
[17:06:49] <twnqx> i am cooling limited though :P
[17:07:00] <twnqx> because i am running stock software
[17:07:35] <twnqx> and there are other limits you hit with that
[17:07:44] <twnqx> memory bandwidth, for example
[17:07:45] <BJfreeman> I am old school and like to seperate into different modules
[17:09:08] <BJfreeman> designed my first muliple cpu with executive and dual ported ram in 76
[17:09:44] <specing> got it to silicon?
[17:10:54] <BJfreeman> it is as far as I want to take it, on modules
[17:11:04] <BJfreeman> in modules
[17:11:17] <specing> then you're not cool.
[17:11:50] <BJfreeman> from a manfuacturing and supplier point of view I am