00:00:00 --- log: started forth/04.05.08
01:24:36 --- quit: iehon ("Zzz.")
01:40:54 --- join: Serg (~knoppix@193.201.231.126) joined #forth
04:05:35 --- quit: Serg (Read error: 110 (Connection timed out))
04:12:30 --- join: qFox (C00K13S@cp12172-a.roose1.nb.home.nl) joined #forth
04:46:12 --- join: tathi (~josh@pcp02123722pcs.milfrd01.pa.comcast.net) joined #forth
06:04:10 --- quit: tathi ("leaving")
06:56:17 --- join: tathi (~josh@pcp02123722pcs.milfrd01.pa.comcast.net) joined #forth
07:49:49 --- quit: chandler ("Foo!")
07:49:59 --- join: kc5tja (~kc5tja@66-74-218-202.san.rr.com) joined #forth
07:50:06 --- mode: ChanServ set +o kc5tja
08:04:17 --- quit: cmeme (Connection reset by peer)
08:04:34 --- join: cmeme (~cmeme@216.184.11.30.unused.swcp.com) joined #forth
08:26:47 <kc5tja> OK, time to work one some Kestrel stuff.
08:27:34 <kc5tja> I tried an arrangement involving a host of CPLDs; however, these chips would all add up in both cost and board space, so it looks like an FPGA is the only solution to keep costs within managable levels.
08:28:02 <kc5tja> The problem is, FPGAs are definitely surface mount components, without the possibility of using a socket (sockets for 100+ pin devices tends to cost more than the chips they socket!).
08:31:20 --- join: [-aXe-] (~axe@pcp03956119pcs.sarast01.fl.comcast.net) joined #forth
08:31:20 --- quit: [aXe] (Read error: 104 (Connection reset by peer))
08:46:06 --- quit: cmeme (Read error: 54 (Connection reset by peer))
09:03:44 --- join: cmeme (~cmeme@216.184.11.30.unused.swcp.com) joined #forth
09:11:42 <kc5tja> Wow, I never thought I'd resurrect the FTS1002 K-bus interface for the Kestrel.  We are currently looking at two CPLD chips (approximately 84 pins each), plus the MIA chip (an FPGA of at least 100 pins).
09:12:22 <kc5tja> The FTS1002 is the CPU/K-Bus bridge, which also does partial address decoding and interrupt concentration.
09:13:21 <kc5tja> The FTS1003 (the newest chip design) is the K-Bus Arbiter, which really isn't a true arbiter; more like a simple multiplexor.  It multiplexes the MIA and CPU devices on the RAM/ROM/IO bus.
09:13:51 <kc5tja> And then there is the FTS1101, the Media Interface Adapter (MIA), responsible for video, and if I can fit it in, audio too.
09:16:59 <kc5tja> Accessing ROM, under this design, will no longer affect the video or audio streams either.
09:19:33 --- quit: cmeme (Read error: 54 (Connection reset by peer))
09:20:29 <kc5tja> Accessing the MIA's registers will definitely interfere with the video or audio stream though.
09:21:13 <kc5tja> Unless I have the bus arbiter delay the CPU until the MIA chip is ready for CPU transactions.  That'll definitely work.
09:21:54 --- join: cmeme (~cmeme@216.184.11.30.unused.swcp.com) joined #forth
09:22:46 <kc5tja> Yeah, I am definitely liking this approach.  It's not as cheap as I'd like, but when you have a bus running at 25.175MHz, three-state buffers tend not to work well at those speeds, I don't think.
10:00:05 --- quit: tathi ("leaving")
10:25:19 --- join: Sonarman (~matt@ppp-66-124-254-196.dsl.snfc21.pacbell.net) joined #forth
11:35:32 <kc5tja> OK, just trying to figure out the quickest, easiest way to get a working, capable, imminently hackable video design in the Kestrel.
11:35:38 <kc5tja> And I am thinking it'll be display-list oriented.
11:36:37 <kc5tja> In particular, the instruction "set" the video timing processor will execute will consist of two instructions: CP (copy register A into register B), and LD (load immediate data into register).
11:36:43 <kc5tja> E.g., it'll be a MOVE architecture coprocessor.
11:43:06 <Sonarman> what's a display-list?
11:44:06 <kc5tja> A display list is a series of coprocessor instructions which the video display coprocessor interprets (hence the term, "display list"), instructing it on how to render the display, in real-time.
11:45:18 <Sonarman> so when the CPU wants to change something about how video is displayed, it copies a bunch of coprocessor instructions to the coproc's code buffer?
11:45:26 <Sonarman> or code space or whatever
11:45:29 <kc5tja> Yes
11:45:57 <kc5tja> The video processor fetches the display list code via DMA.  The video processor then interprets the instructions on its own time (synchronized by the dot clock).
11:46:13 <kc5tja> This is how the Atari 8-bit computers and the Amiga series of computers worked.
11:46:48 <Sonarman> is that kind of like what the fancy video cards do "shaders"?
11:46:54 <kc5tja> no idea.
11:47:04 <kc5tja> I can't imagine they'd be at all the same though.
11:47:30 <Sonarman> ok
11:47:37 <kc5tja> The video processor I'm describing does things like control the horizontal and vertical sync pulses, loading the bitplane pointer registers to point to the proper video data, controls the color palette registers, etc.
11:47:51 <kc5tja> I distinguish between video processor and *graphics* processor.
11:48:22 <kc5tja> The former tends to be dedicated more towards video refresh purposes (note: it runs in real-time!!), versus the latter, which tends to concentrate more on actually rendering the graphics to the frame buffer.
11:48:26 <kc5tja> The two are orthogonal.
11:48:44 <kc5tja> The Amiga, for example, had both the Copper (video timing coprocessor) and the blitter (video graphics coprocessor).
11:49:34 <Sonarman> Cool. thanks for explaining :)
11:53:49 <kc5tja> no problem.
11:54:39 <kc5tja> I wish I had single pixel resolution when executing display list instructions though.  But since I only have an 8-bit bus, and coprocessor instructions are going to be 16-bits wide, that won't happen.  :)
11:55:31 <Sonarman> I'm sorry, but... "single pixel resolution"? :)
11:56:27 <kc5tja> Well, think about it.
11:56:50 <kc5tja> By the time the video chip has fetched one instruction (16 bits = two bytes), the chip will have displayed two pixels on the screen.
11:57:28 <kc5tja> That means that, under no circumstances, can I ever get any kind of video effect to ever happen on any single, arbitrary pixel.
11:57:45 <kc5tja> The minimum resolution the video timing processor has, for any instruction, is two pixels.
11:58:41 <kc5tja> Also, using a display list means I need five DMA channels for the video chip, instead of four (four bit-planes, plus one coprocessor channel).
11:59:23 <Sonarman> four bit-planes = 16 colors?
11:59:56 <Sonarman> anyway, i'll stop asking questions, and just read the docs when they come out :)
12:00:58 <kc5tja> Yes, four bit-planes makes for 16 colors.
12:01:06 <kc5tja> I don't mind answering questions.
12:02:43 <Sonarman> I have more, but I have to go now :)
12:02:48 <Sonarman> Thanks a lot, though
12:06:46 <kc5tja> np
12:24:40 --- join: theFox (poohka@user-v8lds28.dialup.mindspring.com) joined #forth
12:25:13 <Robert> Hi
12:26:03 <theFox> hi
12:31:11 --- quit: theFox ()
12:31:45 <I440r> argh thefix was here
12:31:50 <I440r> erm the fox even
12:31:52 <I440r> lol
12:31:59 <I440r> was that jeff fox ?
12:50:50 <Robert> I think so..
13:01:47 <kc5tja> Yes.
13:01:53 <kc5tja> I'm off to get some food.  back in a bit.
13:25:04 --- quit: cmeme (Read error: 54 (Connection reset by peer))
13:27:52 <kc5tja> back
13:29:58 --- join: cmeme (~cmeme@216.184.11.30.unused.swcp.com) joined #forth
13:56:15 <kc5tja> Block diagram of the Kestrel is up on the Kestrel pages.
14:00:11 <kc5tja> And, actually, the FTS1003 really ought to be called the FTS1102 chip.  :/  I was thinking it had a native 65816 bus interface for some reason.
14:20:00 --- join: lalalim (~lalalim@p508AB4F7.dip.t-dialin.net) joined #forth
14:23:29 --- quit: lalalim_ (Read error: 60 (Operation timed out))
14:34:44 --- join: TheBlueWizard (TheBlueWiz@207.111.96.118) joined #forth
14:34:44 --- mode: ChanServ set +o TheBlueWizard
14:34:54 <TheBlueWizard> hiya all
14:35:11 <Robert> Hi :)
14:35:32 <TheBlueWizard> hiya Robert
14:41:09 --- join: Frek (~anvil@h33n2fls31o815.telia.com) joined #forth
14:41:35 <kc5tja> re TheBlueWizard 
14:41:53 <kc5tja> I think I finally settled on a system architecture for the Kestrel.
14:42:10 <kc5tja> http://www.falvotech.com/kestrel.html has a block diagram detailing the major functional components of the Kestrel as a computer.
14:44:54 <TheBlueWizard> hiya kc5tja...sounds good :)
14:45:10 <TheBlueWizard> will take a look after the TV show's over
14:45:34 --- quit: madgarden ("*frotz*")
14:46:10 --- join: madgarden (~madgarden@Kitchener-HSE-ppp3576712.sympatico.ca) joined #forth
14:46:15 <kc5tja> wb madgarden 
14:46:26 --- join: snowricha (~richard@adsl-068-209-159-248.sip.shv.bellsouth.net) joined #forth
14:46:48 <madgarden> Hi!
14:47:15 <snowricha> hello
14:47:24 <madgarden> Greetings.
14:47:33 <madgarden> Still trying to stop a damn ball from going through a paddle.
14:47:38 <snowricha> salutations.... :) 
14:47:50 <snowricha> pong?
14:47:57 <madgarden> Sorta. Air hockey.
14:48:04 <madgarden> Pong's not quite so involved. :P
14:48:20 <snowricha> air hocky can get your fingers pinched
14:48:44 <kc5tja> madgarden: Not sure if you noticed; but I have a block diagram of the Kestrel online.
14:48:49 <kc5tja> Hello snowrichard!
14:49:19 <snowricha> this is your forth computer design?
14:49:33 <kc5tja> Yep.  :)
14:50:11 <madgarden> Ah cool.
14:57:56 <kc5tja> I'm going to be working on the FTS1002 core design now, I think.
14:58:01 <kc5tja> I'll save the MIA chip design for later.
15:13:53 <TheBlueWizard> read the webpage on Kestrel....hmm...is FTS100x a PLA?
15:21:39 <kc5tja> FTS1002 and FTS1003 are CPLDs.
15:21:45 <kc5tja> FTS1101 is an FPGA design.
15:21:53 <kc5tja> Note: FTS1x0x are MY part numbers.
15:21:59 <kc5tja> FTS == Falvo Technical Solutions.
15:22:09 <TheBlueWizard> I see...I figured that much :)
15:22:39 <TheBlueWizard> looks nice though
15:22:48 <kc5tja> The FTS1003 is a gigantic 24-bit 1-of-2 multiplexor, for the most part (well, mostly; it's a real, honest-to-goodness 3-way bus switch, but it can be thought of as a mux).
15:24:15 <kc5tja> And that's assuming I can fit it inside the chip.  I may end up removing the FTS1003 and placing bus arbitration logic inside the FTS1101, and relying on external bus three-state chips to deal with multiplexing.
15:24:20 <kc5tja> It'd be ugly, but it'd work.
15:34:44 * TheBlueWizard nods, and notes Amiga engineers had done a bit of "ugly" hacks with those custom chips in a similar way
15:35:11 <kc5tja> Yeah, but they also had a bigger budget to afford a bigger printed circuit board with.  :-)
15:35:33 <kc5tja> I'm cost constrained to about $130 for the product, and over half of that is going to be spent on the PCB itself.
15:36:13 <kc5tja> And, that price must also include the profit that I make from it too.
15:36:19 <TheBlueWizard> PCB costs that much?? hmm!
15:36:29 <kc5tja> I'm charged by the square inch.  :)
15:36:42 <TheBlueWizard> hmm
15:36:52 <kc5tja> And in low quantities, we're looking about $0.20 or so per square inch.
15:36:55 <kc5tja> Yeah, it's pretty expensive
15:37:37 <kc5tja> This is why most manufacturers turned to surface mount components -- the cost of the PCB, not the cost of the part.
15:39:23 <TheBlueWizard> interesting....and manufacturers also like slots, especially RAM slots, to cut down on cost too
15:39:40 <kc5tja> I'm also going that route.
15:40:00 <kc5tja> I wanted the board to fit in a pizza box when I started.
15:40:11 <kc5tja> I'm now realizing that that isn't possible, at least in a cost-effective manner.
15:41:07 <TheBlueWizard> a standard pizza box would be something like 1-1/2' by 1-1/2' by one inch...big in my book
15:42:08 <kc5tja> Yes.  But, my point was, I originally envisioned a completely flat board, a la Amiga 1000 or Amiga 500 board design.
15:42:25 <kc5tja> Something that would fit in a flat, relatively thin enclosure, so that the monitor can sit directly on top of it.
15:42:47 <kc5tja> I was even planning, for my own custom enclosure, of having a keyboard garage.
15:43:34 <TheBlueWizard> ah...cool...I thought it might look more like C-64...toteable
15:43:54 <kc5tja> I wanted to make either design possible.
15:43:54 <TheBlueWizard> though A500 is certainly toteable
15:44:02 <TheBlueWizard> I see
15:44:34 <kc5tja> But since I lack an internal keyboard, I was going to concentrate on the A1000-style design more than the A500 design.
15:45:37 <kc5tja> I was probably going to build my custom case for it out of papier mache too -- start recycling some of that junk mail I keep getting.
15:46:06 <TheBlueWizard> makes sense, since it's hard to manufacture a fusional CPU/KBD thingie like C-64 or A500 these days, esp. in a low volume manufaction
15:46:17 <kc5tja> Yep, exactly.
15:46:35 <TheBlueWizard> lol re: junk mail --> papier maché computer
15:46:56 <kc5tja> Doubtlessly cheaper than having a case injection molded.
15:47:50 <kc5tja> Just don't get it wet.  :D
15:48:15 <TheBlueWizard> if it's possible to get dead laptops (funcxtional keyboard, but screen got shot, mobo got shot, etc....maybe can repurpose it for Kestrel, almost for free, provided it has right geometry
15:48:38 <kc5tja> I'll leave that to the open source community to figure out how to do.
15:48:42 * TheBlueWizard watches your coke...too close to the computer... :)
15:48:44 <kc5tja> Kestrel is GPLed.
15:48:55 <kc5tja> Actually, I drink water.
15:48:56 <kc5tja> :)
15:49:02 <[-aXe-]> hi guys
15:49:02 <kc5tja> I haven't had a coke in a while actually.
15:49:05 <[-aXe-]> I440r: you here dude?
15:49:07 <kc5tja> re [-aXe-] 
15:49:12 * TheBlueWizard nods...and notes the community is exceedingly creative...at times :)
15:50:08 <[-aXe-]> Wizard: there's a bunch of semi-dead laptops on eBay... obviously they want a lil money for 'em, but if all you want is components to cannibalize, you can get some good deals :)
15:51:33 * kc5tja nods
15:54:52 <I440r> yea
15:54:54 <I440r> im here
15:59:21 <[-aXe-]> you figure it out yet?
15:59:24 <[-aXe-]> or is it beatin' you down? ;)
16:01:19 <I440r> well its kinda complex, i know this is the code calculating the checksum but what form does the data being checksummed take
16:01:44 <I440r> i ran your url as is through the code and it doesnt generate the expected result
16:01:53 <[-aXe-]> hmmm
16:01:54 <I440r> so thers something else going on
16:02:02 <[-aXe-]> I've got a few more URLs and checksums if you need 'em
16:02:17 <I440r> sure
16:02:25 <kc5tja> TheBlueWizard: I just downloaded a Verilog 6502 implementation, that I'm going to hack to make it look more like a 65816 for testing purposes.
16:02:42 <kc5tja> TheBlueWizard: It's not GNU licensed, so I won't redistribute it.  But it'll be good for development purposes.
16:02:47 <[-aXe-]> okies, hold on a sec
16:04:58 <TheBlueWizard> kc5tja: um, it's big, and it would require an expensive software to simulate it...if I'm not mistaken
16:05:29 <kc5tja> TheBlueWizard: Icarus verilog compiles the Verilog for it no problems.  It'll probably take a long time to emulate, but that's OK -- it's the results I'm after.
16:06:01 <kc5tja> TheBlueWizard: And the total source for the bc6502.v module is less than 40KB of code.
16:06:04 <kc5tja> ls
16:06:06 <kc5tja> oops
16:06:51 <[-aXe-]> hmm...
16:06:55 <[-aXe-]> Mark...
16:06:59 <I440r> y ?
16:06:59 <[-aXe-]> try prefixing the URL with info:
16:07:02 <I440r> ya ?
16:07:08 <I440r> info:! ok
16:07:13 <I440r> brb
16:07:14 <[-aXe-]> the search query begins info:http://
16:07:26 <[-aXe-]> I didn't think before if that may be a factor in generating the checksum
16:07:51 <[-aXe-]> it may not be, but it doesn't hurt to rule it out
16:08:47 <TheBlueWizard> checksumming a webpage?
16:09:28 <[-aXe-]> and the trailing slash is important
16:09:38 <[-aXe-]> http://www.domain.com produces a different checksum to http://www.domain.com/
16:09:59 <[-aXe-]> we're trying to figure out how a particular application generates its checksums for URL strings
16:10:17 <[-aXe-]> basically so we can write functions in other languages to produce identical checksums
16:10:25 <[-aXe-]> from the same URL strings
16:10:58 <TheBlueWizard> ah....I'm handy with a few pgmming languages
16:11:19 <[-aXe-]> well, the only reference we have is already compiled
16:11:25 <I440r> whats the checksum for your page ?
16:11:27 <I440r> in hex
16:11:28 <[-aXe-]> so we're decompiling it and going through the ASM to try n' figure it out
16:11:38 <[-aXe-]> which page?  I just E-Mailed you 4 URLs
16:11:47 <I440r> the one you gave me the other
16:11:49 <I440r> day
16:11:52 * kc5tja reports you two violators of the DMCA. :D
16:11:52 <[-aXe-]> hold on
16:11:55 <TheBlueWizard> you don't have the source code for checksumming?
16:12:03 <[-aXe-]> lemme send you the E-Mail again, along with Dec & Hex checksums
16:12:04 <TheBlueWizard> kc5tja: lol
16:12:11 <I440r> nooo dont email lol
16:12:20 * kc5tja is kidding
16:12:25 <I440r> just tell me what the checksum was for the test.html url
16:12:26 <[-aXe-]> kc5tja: we're not breaching the DMCA.. we're not stealing somebody else's code, just figuring out an algorythm :)
16:12:33 <[-aXe-]> ok, hold on
16:12:37 <[-aXe-]> I'll have to load it back up again
16:13:06 <I440r> http://www.bigwebmaster.com/test.html
16:13:14 <[-aXe-]> 6538814816
16:13:16 <[-aXe-]> that's in decimal
16:13:27 <[-aXe-]> 185BE6560
16:13:28 <I440r> give it to me in HEX
16:13:32 <I440r> i dont work in decimal lol
16:13:32 <[-aXe-]> that's Hex with the 6 at the beginning
16:13:37 <I440r> decimal is for NON coders :P
16:13:45 <I440r> without the leading 6
16:13:52 <[-aXe-]> 201DA960
16:13:55 <[-aXe-]> that's without the leading 6
16:14:08 <[-aXe-]> yeah, I was gettin' you both, to be sure
16:14:23 <I440r> not getting either result
16:14:29 <[-aXe-]> what are you getting?
16:14:43 <I440r> i gotta go out for a bit, ill be back to work on this tho
16:14:47 <[-aXe-]> okies
16:14:59 <[-aXe-]> Blue: Nope, we don't have the original source
16:15:25 <[-aXe-]> only the company that wrote the software have the original source, but it is crackable... a handful of other people have done it
16:15:35 <TheBlueWizard> is it a standard checksum protocol? or is it a proprietary method?
16:15:41 <[-aXe-]> proprietory
16:15:50 <I440r> bbl
16:15:57 <[-aXe-]> take it easy Mark
16:16:04 <TheBlueWizard> ah ok...then have to disassemble it, decipher it, etc...yep
16:16:30 <kc5tja> I guess my next question would be why you're interested in it.
16:16:44 <[-aXe-]> Blue: yup
16:17:24 <[-aXe-]> kc5tja: purely for personal use
16:18:21 <[-aXe-]> the software that uses it is only available for the windows platform..
16:18:32 <[-aXe-]> I basically need to have the functionality in Linux
16:18:34 <kc5tja> Ah.
16:18:46 <kc5tja> Well, like I said above, I was just joking about the DMCA stuff.
16:18:47 <TheBlueWizard> cloning it, I see
16:18:52 <[-aXe-]> but it's not something that'd be released for the masses
16:18:56 <[-aXe-]> I know you were :)
16:19:20 * kc5tja is trying to hack the 6502 Verilog code to make it have a 24-bit address space, even though the instruction execution code is still that of an 8-bit CPU.
16:19:28 <TheBlueWizard> by cloning I'm referring to the algorithm, of course
16:19:37 <kc5tja> Four zero-page locations are reserved, a la CSG6509 CPU.
16:19:56 <kc5tja> $00 is the bank address byte to use when reading from memory via the abs,X addressing mode; $01 is used for memory writes.
16:20:14 <kc5tja> $02 is the bank address byte to use when reading from memory via the (zp),Y addressing mode; $03 is used for memory writes.
16:20:26 <kc5tja> All other addressing modes implicitly assume bank zero.  Always.
16:21:59 <TheBlueWizard> interesting...though a bit awkward
16:22:23 <kc5tja> Well, if you set those four locations to zero, then it'll behave exactly like a 64KB equipped 6502.
16:23:09 <kc5tja> And really, it's not that awkward; it's impossible (or nearly so) to perform cross-64K-boundary memory copies efficiently without splitting the read and write cycles.
16:24:29 <kc5tja> Also, remember too, that this is intended entirely and purely for testing and development purposes.
16:24:44 <kc5tja> I already have a bucket load of 65816 CPUs, which have true 24-bit addressing capabilities.
16:24:52 <kc5tja> I have no need for a jury-rigged 6502 clone.
16:25:04 <kc5tja> (If I were to make my own CPU, it'll be a stack CPU anyway)
16:30:52 <TheBlueWizard> bucketload of 65816s?  how come you got that many?
16:31:06 <kc5tja> Western Design Center has a minimum order requirement of $100 per order.
16:31:37 <TheBlueWizard> and each CPU cost maybe $5, right?
16:31:43 <kc5tja> I got 7 65816s, 2 6522s, and the programmers manual for the chips, which was all I really wanted.  I decided to get the chips because the book alone didn't meet the requirement.  :)
16:31:47 <kc5tja> Yes.
16:32:03 <TheBlueWizard> I see
16:32:04 <madgarden> Enough already! Just build me my damned Kestrel... JEEZ!
16:32:06 <madgarden> ;)
16:32:40 * TheBlueWizard tosses madgarden a Kestrel T-shirt, just to placate him :)
16:32:55 <kc5tja> heh
16:33:09 <kc5tja> madgarden: I'd like to see YOU try to build good quality hardware for super cheap and pull it off quickly.
16:34:07 <madgarden> Sure! Did it in college a few times. :P
16:34:37 <madgarden> But then again, it was mostly wire-wrapped, got some parts as samples, etc.
16:35:51 --- quit: scope (Client Quit)
16:36:17 <kc5tja> Yes, well, this design isn't exactly your every day college electronics project!
16:36:46 <madgarden> Surely not!
16:38:07 <madgarden> But, you should be able to get a prototype together fairly cheaply, soon I hope?
16:38:57 --- join: scope (~junk@njd.paradise.net.nz) joined #forth
16:39:34 <madgarden> See? You've already got a free scope. :D
16:40:31 <kc5tja> No, because I need programmable logic.
16:40:47 <kc5tja> That means I need to layout printed circuit boards and the like.
16:44:13 <kc5tja> I was thinking of building everything like a bunch of Legos -- e.g., have a dedicated CPU module, a dedicated MIA board, etc.
16:44:22 <kc5tja> And these boards would snap into a common back-plane bus.
16:44:51 <kc5tja> So, basically, it'd be more like an IBM XT in design and implementation than a Commodore 64 or Amiga 1000.
16:45:06 <kc5tja> It'd run the same software -- no real differences on the software side.
16:45:26 <kc5tja> But the circuit WOULD be more expensive then, because (a) I need more inventory, and (b) all those backplane connectors cost money.  :/
16:46:06 <kc5tja> The form factor of such a computer would be more of a cube though.
16:46:14 <madgarden> Cubes are cool.
16:46:42 <kc5tja> I was thinking maybe I should go with a cylindrical shape, like a Cray, but then I felt that such a shape should be reserved for the Raven.  :D
16:46:50 <kc5tja> Yeah, it's just keeping the costs down.
16:47:09 <kc5tja> If cost is no concern, then I can definitely bang something out *reasonably* quickly (I still have that learning curve with the programmable logic though).
16:47:26 <madgarden> Is it necessary to proto the modularity?
16:47:35 * TheBlueWizard just has a crazy thought...what if one would just throw out PCBs althogether? just pure plug them together? nah...too crazy
16:47:50 <kc5tja> TheBlueWizard: You need a substrate to solder everything to.
16:48:06 <kc5tja> Otherwise, you'll end up with a mess of wires, and the builder will get hopelessly confused.
16:48:08 <TheBlueWizard> mmhmm
16:48:23 <kc5tja> Maybe for us expertz, "dead bug style" is acceptable.
16:48:28 <kc5tja> But not for the average homebrewer.
16:48:34 <kc5tja> madgarden: I don't understand your question.
16:48:46 <kc5tja> The Kestrel was NEVER intended to have slots.
16:48:48 <kc5tja> Never.
16:49:09 <Herkamire> I messed up several times putting ends on ethernet cables because I didn't get the 8 wires in the right order
16:49:11 <kc5tja> It was to be built, like I've said so many times before, like a C64 or Amiga.
16:49:26 <kc5tja> Single board computer, in essence.
16:50:08 <kc5tja> SBCs are cheaper to fabricate (though not necessarily easier to debug for me, but that is MY issue, not the builder's).
16:50:17 <madgarden> kc5tja, I mean I'd like to see the thing running on a wire-wrapped board before I'd even care about the form-factor.
16:51:23 <kc5tja> true enough; too bad a wire wrap socket for the parts used on the Kestrel would cost up to 3 times the cost of the part its socketing!
16:53:03 <kc5tja> And that's assuming you can even find them; I absolutely don't think you can find ANY wire-wrap sockets for a 144-pin package, considering that's likely to be the smallest package that can hold the FPGA for the MIA chip.
16:53:28 --- nick: TheBlueWizard -> TBW-out-shopping
16:54:54 <TBW-out-shopping> gotta go...bye all
16:55:03 <kc5tja> laters TBW-out-shopping 
16:55:18 --- part: TBW-out-shopping left #forth
16:56:10 <kc5tja> madgarden: What it boils down to is this: Every major component would need a custom PCB that has hand-soldered wire-wrap lugs on it.
16:56:22 <kc5tja> Each board is going to cost me a fair chunk of change to produce.
16:56:54 <madgarden> Blargh.
16:57:02 <kc5tja> :)
16:57:36 <madgarden> How about wiring up a few big, honking 68000's in parallel? :)
16:57:50 <kc5tja> Do you have the cash to afford 68000s?
16:57:59 <kc5tja> Do you even know where to *PURCHASE* *NEW* 68000s?
16:58:10 <kc5tja> 'cos the best I could do was locate a 68020 chip for, get this, $250.
16:58:15 <madgarden> :O
16:58:18 <madgarden> Hmm.
16:58:28 <madgarden> Well, I've got a couple Z80's in my toolbox.
16:58:33 <madgarden> :)
16:58:39 <kc5tja> Useless without the logic to hook them up with.
16:58:49 <kc5tja> The problem isn't the CPUs.
16:58:59 <kc5tja> The problem is what you hook the CPU *up* to.
16:59:00 <madgarden> I could swear I still have the 68HC11 around somewhere.
16:59:32 <kc5tja> Well, what are you looking for?
16:59:40 <kc5tja> Are you looking for a box that has a CPU, some RAM, some ROM, and a UART?
16:59:47 <kc5tja> No video, no audio, no nuttin'?
16:59:52 <kc5tja> Because that is trivially easy.
17:00:07 <madgarden> That could work.
17:00:14 <kc5tja> But it's uninteresting.
17:00:20 <madgarden> Yep.
17:00:36 <madgarden> But, at least it works as an initial prototype.
17:00:39 <kc5tja> There's no video, no audio, no peripheral interconnect bus, maybe a bunch of raw I/O pins, and that's it.
17:01:25 <kc5tja> But it's not what I have offered, and what people have expressed to pay for.
17:01:59 <kc5tja> Paying $100 for a box that can't even beep, let alone print "Hello world!" to the screen (indeed, WHAT screen?) is ludicrous.  At least, to me.
17:02:35 <madgarden> The prototype would not be sold, it would be used as a marketing device and proof that you can deliver something at some point.
17:03:12 <madgarden> If you can prove this, then more people will pre-order.
17:03:34 <kc5tja> well, nobody has pre-ordered, and certainly, I don't like the idea of pre-ordering anyway.
17:03:44 <kc5tja> Right now, I have a donation button on the page, but that's about it.
17:04:02 <madgarden> pre-order donate nip
17:04:37 <kc5tja> and I still need the custom logic for the FTS1002 chip, which does the address decoding, bus demultiplexing on the CPU side, etc.
17:04:49 <kc5tja> Though that is easier to get right, by far.
17:06:36 <madgarden> You don't need custom logic on a chip for that stuff.
17:07:06 <kc5tja> I do if I want to keep circuit size small.
17:07:27 <madgarden> You don't need to keep the circuit size small in a prototype.
17:07:44 <kc5tja> Yes, I do.  I'm not made of money.
17:08:28 <kc5tja> I would love the ability to just slap parts together and be done with things.
17:08:35 <kc5tja> Incremental construction is the best thing.
17:08:41 <madgarden> Do you think you'll get more donations with or without a prototype and a webpage divulging its merits with pictures of its coolness?
17:08:42 <kc5tja> But unfortunately, it's expensive to realize.
17:09:13 <kc5tja> Obviously the latter, but it's also obvious that I just plain *cannot* afford to prototype right now.
17:09:25 <kc5tja> Wire wrap sockets are just too damn expensive.
17:09:26 <madgarden> You should be able to get a lot of what you'd need for a prototype, for free, by dumspter diving.
17:09:59 <kc5tja> Sorry, I neither have the time nor resources for that.
17:10:20 <madgarden> I did manage to get my 68HC11 socket for free, by requesting a sample.
17:10:28 <kc5tja> Is it wirewrap?
17:10:32 <madgarden> Yep.
17:10:32 <kc5tja> Or is it solder?
17:10:54 <kc5tja> Because the last I checked, the cost of an 84-pin PLCC wirewrap socket was at least as much as the PLCC it's socketing.
17:11:30 <madgarden> That's probably why I tried for the free sample.
17:12:12 <kc5tja> Well, at any rate, this is all future-speak.
17:12:18 <kc5tja> I don't even have a concrete design in place yet.
17:12:33 <madgarden> Sure! But it can't hurt to explore some ideas.
17:12:46 <madgarden> One idea often leads to another more viable one.
17:13:06 <madgarden> And I really don't think you want to include concrete in your design! :O
17:13:11 <kc5tja> Believe me, I've tried a number of ideas, and the one I have right now seems to be the cheapest overall solution.
17:13:25 <kc5tja> Concrete?
17:13:32 <madgarden> :D
17:13:44 <madgarden> <kc5tja> I don't even have a concrete design in place yet.
17:13:52 <kc5tja> An idiom, dude.
17:13:57 <madgarden> Just being a smart-ass, dude.
17:14:26 <madgarden> But sure, go ahead and call me an idiom!
17:14:28 <madgarden> ;P
17:16:08 <kc5tja> OK.
17:18:17 <madgarden> kc5tja, you really are a Vulcan. ;)
17:18:50 <kc5tja> Yes.
17:18:53 <kc5tja> I am very literal.
17:20:15 <madgarden> It's all good. Just literally get me my frickin' Kestrel already! :) 
17:23:00 <kc5tja> Just think of how long it took me to get the block diagram up.
17:24:46 --- quit: Frek ("Client exiting")
17:24:47 <madgarden> And what a bonny diagram she is!
17:24:56 <kc5tja> Bonny?
17:25:01 <madgarden> Aye, laddy!
17:31:26 <kc5tja> My first goal is to get the computer to execute code from EEPROM, of course.
17:31:58 <kc5tja> A VIA chip will be resident to handle Kestrel/PC communications (via a software-implemented UART).
17:32:21 <kc5tja> Actually, no.
17:32:24 <kc5tja> Scratch that.
17:32:36 * madgarden scratches that. It leaves a mark.
17:32:39 <kc5tja> I forgot the VIA had an internal serial port.  I'll use that, and just use a cable to the PC via the parallel port.
17:33:44 <kc5tja> That'll actually be the very start of the PIB too.
17:35:37 <kc5tja> But, I want to get everything working under simulation before I even begin to invest in hardware.
17:35:49 <kc5tja> I want to make sure my *ideas* work long before I spend a cent on hardware.
17:39:03 <madgarden> Certainly
17:55:10 <madgarden> I don't suppose anyone in here has Allegro installed, AND is keen with vector math?
17:58:12 <kc5tja> I fail that precondition.
17:59:45 <madgarden> I don't suppose anyone in here doesn't have Allegro installed, but is smart enough with vector math to be able to look at a function that's not quite working correctly? :)
18:00:19 <kc5tja> Hmm....if you look at my college transcripts, I also fail that precondition.
18:00:19 <kc5tja> :)
18:00:26 <kc5tja> But what seems to be giving you issues?
18:01:04 <madgarden> Well... I've got a paddle, and a ball, both round.
18:01:29 <madgarden> Now, the ball can be bouncing like a mad... thing, and it will stop when it hits the paddle.
18:01:39 <madgarden> If I move the paddle, I can push the ball around.
18:01:53 <madgarden> However, if the paddle moves too fast, the ball will pop through it.
18:02:05 <madgarden> And it AIN'T SUPPOSED TO DO THAT!
18:02:48 <kc5tja> It's not a bug -- it's a feature.  Blame it on Heisenberg's Uncertainty Principle, and Schrodenger's wave functions, both of which fully predict this outcome in the real world.  >:-)
18:03:04 <kc5tja> Seriously, what do you mean by "push the ball around?"
18:03:15 <madgarden> Haha.
18:03:17 <kc5tja> What game are you trying to make, first of all, so that I can have some context.
18:03:21 <madgarden> Well, what I mean is...
18:03:24 <madgarden> (air hockey)
18:03:50 <madgarden> The ball bounces around the square arena. It will hit the paddle, and right now, stop (because I commented out the bounce code).
18:04:05 <madgarden> If I push the paddle into the ball, it will push the ball ahead of it.
18:04:16 <madgarden> (normally it would add velocity to the ball)
18:04:32 <madgarden> But right now, I have it stopping the ball as soon as it touches the paddle.
18:04:36 <madgarden> (for testing)
18:05:41 * kc5tja nods
18:06:00 <kc5tja> But if you push too far too fast, the ball appears behind the paddle?
18:06:05 <madgarden> Yep.
18:06:50 <madgarden> It's supposed to calculate where they will meet based on velocity, and not pass through each other.
18:06:57 <kc5tja> What is the cut-off for this behavior?  E.g., if the paddle moves less than the diameter of the ball, does it still pop behind it?
18:07:33 <madgarden> Actually, it will overlap the paddle a little bit before it pops through. Should never overlap.
18:09:10 <kc5tja> hmmm
18:09:59 <kc5tja> I don't know.
18:10:30 <kc5tja> I would probably add some code to detect the overlap condition, and based on how far it overlaps, adds velocity to the ball away from the paddle.
18:11:33 <madgarden> Yea, that's basically what it does already. :-/
18:11:40 <madgarden> (that's why I can push the ball at all)
18:11:58 <madgarden> Well, it adjusts how far the ball was about to move.
18:12:10 <madgarden> It also pushes the ball based on where the paddle is going.
18:12:12 <kc5tja> If that code runs on every input event related to the paddle, then it shouldn't ever have a problem.
18:12:46 * kc5tja can't think of a reason why it wouldn't work.
18:12:47 <kc5tja> :/
18:13:03 <madgarden> Well, I can show you the function. It's all relatively simple at this point.
18:15:10 <kc5tja> ok, but I can't guarantee anything.
18:16:29 <madgarden> http://www3.sympatico.ca/ppridham/misc/sounds/speechy.zip
18:16:31 <madgarden> Er...
18:16:34 <madgarden> Wrong thing.
18:16:53 <madgarden> (that's a cheesy little speech synth I made last year)
18:16:55 <madgarden> http://www3.sympatico.ca/ppridham/misc/tmp/nodeball2.zip
18:17:15 <kc5tja> Ahhh, I thought I didn't have to unzip.  
18:17:24 <madgarden> Hmm.
18:17:31 <madgarden> Hold on then...
18:17:38 <madgarden> I can put the code up on a wiki somewhere.
18:17:46 <kc5tja> Got it.
18:18:50 <madgarden> battle.c is where the function is
18:20:43 <madgarden> These two lines are supposed to adjust the ball position:
18:20:43 <madgarden>     ball.mov=vmulf(av, g);
18:20:43 <madgarden>     ball.mov=vsub(ball.mov, (vmulf(bv, g)));
18:21:26 <kc5tja> I'm not seeing it.
18:21:44 <kc5tja> OK, Found it.
18:22:27 <kc5tja> What is vmulf()?
18:22:33 <kc5tja> How does it differ from vmul()?
18:22:36 <madgarden> multiplies a vector by a float
18:22:41 <madgarden> vmul is two vectors
18:25:04 <madgarden> I'm not so sure I am doing the right thing there.
18:25:04 <kc5tja> I'm just not seeing the logic.
18:25:16 --- quit: snowricha ("Leaving")
18:25:41 <madgarden> Yea, you sort of have to follow through from the start of the function. Sorry, it's a work in progress, could be nicer looking. :-/
18:25:54 <kc5tja> What is movevec?
18:26:17 <madgarden> That's just what they called it in the example I was following.
18:26:21 <madgarden> dv
18:26:26 <madgarden> movement vector
18:26:44 <kc5tja> The single-character variable names are awfully confusing to me.
18:26:53 <madgarden> Me too. :)
18:27:41 <madgarden> It's my first shot at this kind of thing. Was going to clean it up after it worked.
18:28:07 <madgarden> For instance... not even sure what to call "d".
18:29:10 <madgarden> ie. what do you call the dot product of the vector between the centres of the balls and their relative velocities?
18:29:28 <madgarden> d, I said. :)
18:29:39 <kc5tja> I really can't follow the code.
18:29:43 <kc5tja> Even from top to bottom.
18:30:08 <kc5tja> In one place, 'd' is used to refer to some kind of distance, while 'dv' is sometimes used, etc.
18:30:45 <kc5tja> The name of the function also made me think that, when it was called, the ball and the paddle has already been knonw to have collided.
18:33:09 <madgarden> Yep. 
18:33:31 <madgarden> Oh well, thanks for taking a look at it anyway.
18:33:38 <madgarden> I have an idea what it might be.
18:34:07 <kc5tja> Sorry I couldn't be of greater help.  But without additional context, I just can't make heads or tails of what's going on in the code.
18:34:41 <madgarden> Yea, at least being able to run it would help somewhat.
18:35:01 <kc5tja> I don't have Allegro.
18:35:20 <kc5tja> Besides, I'm also currently hacking on my pseudo-6502 stuff right now.  :)
18:35:37 <madgarden> No worries.
18:35:58 <kc5tja> I sure do wish that there was a ready-made, out of the box Verilog model of the 65816 CPU.  :(  That would save me a *LOT* of time.
18:36:22 <madgarden> :-/
18:51:47 <kc5tja> Man, this is one of the biggest freakin' hacks I've *ever* had the disluxury of implementing.
18:54:59 <madgarden> What's a hack?
18:55:01 <madgarden> Speaking of hacks, I think I just fixed the problem. :-/
18:55:29 <kc5tja> The only 6502-family Verilog code I could find was for an honest-to-goodness 6502.
18:55:40 <kc5tja> Which is an 8-bit CPU that addresses a monsterous 64KB of RAM.
18:55:50 <madgarden> C64 baby!
18:55:52 <kc5tja> Problem is Kestrel has MEGABYTES of RAM, so I need some facility to hit those upper memory regions.
18:55:52 <qFox> 03:47:20 ** New email received from "Penelope" <%FROM_USER@21cn.com>
18:55:54 * qFox chuckles
18:55:59 <kc5tja> And that's the hack.
18:56:10 <kc5tja> I implemented four special zero-page locations.
18:56:11 <qFox> (that was the actual email-address btw)
18:57:06 <kc5tja> The byte stored at $00 is the upper 8 address bits to use when using a LD* abs,X instruction (where * is the register to load into), $01 does the same for ST* abs,X, $02 for LD* (zp),Y, and $03 for ST* (zp),Y
18:57:43 <kc5tja> The caveat is that you *CANNOT* use those addressing modes to change the four reserved bytes -- those access real RAM underneath those bytes.
18:58:08 <kc5tja> So if you wanted to use the real RAM backing location $00, then you'd have to do something like this:
18:58:11 <kc5tja> LDX #$00
18:58:15 <kc5tja> LDA #$value
18:58:19 <kc5tja> STA $0000,X
18:58:36 <kc5tja> That'd store value at $0000 in RAM, without affecting the special bank address byte configuration.
18:59:07 <kc5tja> of course, the above code assumes that the bank has been set to $00 to begin with.
18:59:10 <kc5tja> If not, you have to do this:
18:59:14 <kc5tja> (prepare yourself!)
18:59:17 <kc5tja> LDA #$00
18:59:19 <kc5tja> STA $00
18:59:21 <kc5tja> STA $01
18:59:26 <kc5tja> LDX #$00
18:59:29 <kc5tja> LDA #value
18:59:32 <kc5tja> STA $0000,X
18:59:39 <kc5tja> It's ugly.  Real ugly.
19:00:08 <kc5tja> This kind of pathological code ought never appear, however, as doing so will interfere with any code that READS from these locations.
19:00:24 <kc5tja> LDA $00 *will* read the value stored in *RAM*, not the value in the special bank register.
19:00:35 <kc5tja> But since STA $00 will update both the register and the RAM, this is usually not a problem.
19:00:45 <kc5tja> It's only a problem when you write wiggity code like the above example.
19:03:17 <madgarden> Well, nobody should be reading from there anyway.
19:03:22 --- quit: qFox ("this is mirc's last attempt of communication...")
19:03:33 <madgarden> kc5tja, want to see my hack?
19:03:52 <kc5tja> Well, you have to read from there if, for example, you need to make a bank-aware 6502 debugger, or multitasking engine, for example.
19:04:06 <kc5tja> But since this is just a hack for design purposes ONLY, I'm not going to worry about it further.
19:04:11 <madgarden> Hm.
19:04:29 <kc5tja> I'm not sure I'd be able to follow your hack.
19:04:38 <kc5tja> I didn't follow the original code to begin with.  :)
19:05:14 <madgarden> Could you perhaps store this data in some latches, accessed as I/O?
19:05:27 <madgarden> And, the hack is quite simple. I don't know why it works, really.
19:05:28 <kc5tja> That's essentially how this stuff works.
19:05:31 <madgarden>     g=distance/dv_mag;
19:05:31 <madgarden>     ball.mov=vmulf(av, g);
19:05:31 <madgarden>     ball.mov=vsub(ball.mov, (vmulf(bv, g-1)));
19:05:38 <madgarden> Note the -1
19:05:43 <madgarden> That's all I added.
19:05:51 <madgarden> Who the fuck knows why I needed that.
19:06:01 <madgarden> But, it seems to work now.
19:06:26 <kc5tja> the four special registers are arranged internally as "write-only" registers, but since the write also goes to RAM at the same time, read-back capability is supplied by RAM.  So, this single hack is really a double-hack.  :)
19:06:54 <madgarden> Heh. 
20:37:02 <kc5tja> GAHH, CRAP!!!
20:37:13 <kc5tja> The 6502 module I downloaded doesn't even implement the 6502 bus timings correctly.
20:37:17 <kc5tja> (it does everything else BUT!)
20:38:03 <kc5tja> OK, I'm just going to have to implement a very simple stack CPU for the purposes of testing the hardware out.
20:38:08 <kc5tja> I see no other way around it.  *sigh*
20:38:46 <kc5tja> Man, that totally sucks.
20:41:08 <kc5tja> Of course, this now opens the possibility of basing the Kestrel on a stack CPU from the get-go.
20:41:15 <kc5tja> What are your opinions on this?
20:41:52 <madgarden> Why not?
20:42:08 <Herkamire> I would love the kestrel to have a stack CPU
20:43:28 <kc5tja> The reason I originally chose the 65816 was because it was cheaper than programmable logic.
20:43:34 <kc5tja> But since I'm using FPGAs and CPLDs anyway....
20:43:55 <kc5tja> Now, here is the next question: should it be 20, 24, or 32 bits wide?
20:44:06 * kc5tja has a preference for 32-bits width, but with a 16-bit external data bus to save pins.
20:44:28 <madgarden> 32 bits, why anything else?
20:44:36 <kc5tja> I'm glad we're on the same page.  :D
20:45:27 <kc5tja> This might simplify a lot of things, actually, as then the video circuitry and CPU can reside on the same physical chip, if I'm lucky.
20:46:07 <madgarden> Since things are so much simpler now, you can also throw on a SID chip! ;D
20:46:26 <kc5tja> I've been looking into sound generation.
20:46:29 <kc5tja> I don't think it's doable.
20:46:30 <kc5tja> At all.
20:46:44 <kc5tja> I would need VERY high clock frequencies to get good PWM output.
20:46:54 <madgarden> Just go for NES-style sound.
20:47:03 <kc5tja> Most FPGAs are good for only 50MHz to 60MHz or so, at least the ones in my price range.
20:47:16 <kc5tja> umm, I still need PWM to generate the audio waveforms.
20:47:24 <madgarden> Triangle wave, square wave, and white noise.
20:47:32 <madgarden> Not much generating required.
20:47:37 <kc5tja> Wrong.
20:47:40 <madgarden> Could do it in software.
20:47:52 <kc5tja> I need to generate *analog* waveforms.
20:47:57 <kc5tja> This requires a DAC of some kind.
20:48:00 <madgarden> DAC
20:48:06 <madgarden> Yea.
20:48:10 <kc5tja> I can't put a DAC on an FPGA.
20:48:26 <kc5tja> I'd need an external DAC chip.
20:48:30 <madgarden> Yes.
20:48:46 <madgarden> I don't recall them being that expensive.
20:49:02 <kc5tja> No, but I was interested in reducing parts count.
20:49:10 <kc5tja> The less parts, the less expensive it is to build.  :)
20:49:30 <kc5tja> BTW, what's wrong with DMA-fed DACs, anyway?
20:49:40 <kc5tja> Do you prefer something like a synthesizer over DMA-fed DACs?
20:50:51 <madgarden> Well, I'd prefer that to no sound.
20:50:55 <madgarden> I like sound.
20:51:30 <madgarden> And there's nothing wrong with a DAC if I can twiddle it to produce sound.
20:51:39 <kc5tja> Of course you can twiddle it.
20:51:44 <kc5tja> ALL DMA fed registers are CPU-tweakable.
20:51:48 <kc5tja> Just like in the Amiga.
20:51:56 <madgarden> Bleep bleep then!
20:51:58 <kc5tja> In fact, I find that to be overwhelmingly the best way to build hardware at all.
20:52:25 <kc5tja> The Amiga's hardware was all originally CPU fed (having its origins in the Atari 2600!!).  The DMA engine was added afterwards to make everything autonomous.
20:56:29 <kc5tja> Actually, I'm wondering if I can borrow some techniques from DDS (Direct Digital Synthesis) to be able to have the benefits of both synthesis and direct-fed DACs.
21:04:08 <kc5tja> I downloaded the datasheet for the 6581 just in case.
21:05:24 <kc5tja> It just won't "feel" right to program a SID chip in a stack CPU assembly language.
21:05:27 <kc5tja> :)
21:13:14 <kc5tja> OK, I'll work up the official announcement that the Kestrel will employ a stack CPU tomorrow (remind me though -- I'll probably forget).
21:17:38 <madgarden> Stack CPU + SID chip. ;)
21:18:20 <kc5tja> No no, no SID chip.
21:18:26 <kc5tja> That'll be left as a pleasant surprise.
21:18:44 <kc5tja> I don't like the lumping of all the different devices together in a single design, anyway.
21:18:54 <kc5tja> It's OK to have several logically separate devices reside on one chip.
21:19:06 <kc5tja> But I do not agree with having N devices in a single *design*
21:19:10 <kc5tja> If that kind of makes sense.
21:20:54 <kc5tja> I'm also thinking of naming the CPU design "OpenMISC 1".
22:36:15 <kc5tja> One *especially* nice thing about going this route: *I* can use *SDRAM* DIMMs!!
22:36:26 <kc5tja> Kiss the 16MB barrier goodbye.
22:36:56 <kc5tja> Oh goodness -- good lord.  And CPU clock speeds can get up to 50MHz too.  ROCK ON!
22:38:01 <kc5tja> Although, I'll probably stick with 25.175MHz just because of the VGA dot-clock.
22:38:11 <kc5tja> Still though, that's more than 4x faster than the 12.58MHz clocked 65816.
22:38:40 <kc5tja> Assuming the RAM can deliver data that fast, of course.
23:01:21 --- join: thelsdj (~adam@24-116-165-168.cpe.cableone.net) joined #forth
23:03:59 <I440r> yo ls !!
23:04:13 <I440r> yall kept that nick longer than any other ive see you with lol
23:06:06 <thelsdj> hah, hmm ya i've kept this a while, don't think i'll ever come up with anything better
23:06:23 <I440r> :)
23:06:35 <I440r> you cant. i already have the best nick there is :P
23:07:05 <kc5tja> HAH!
23:08:56 <thelsdj> i remember back in the day when you tried to teach me some forth, i'm proud to say i've forgotten 100% of it
23:12:03 <I440r> lol
23:12:15 <I440r> well get isforth and read my pages
23:12:18 <I440r> which are incomplete
23:12:31 <I440r> im also going through each page now and making it 4.01 transitional compliant
23:36:34 --- quit: Sonarman ("leaving")
23:59:59 --- log: ended forth/04.05.08