00:00:00 --- log: started forth/06.03.14 00:06:40 --- join: warpzero_ (n=warpzero@wza.us) joined #forth 00:06:41 --- quit: warpzero (Read error: 104 (Connection reset by peer)) 00:53:03 --- join: alahzad (i=xtreme@adsl-66-137-80-201.dsl.lgvwtx.swbell.net) joined #forth 01:21:20 --- join: warpzero (n=warpzero@wza.us) joined #forth 01:21:32 --- quit: warpzero_ (Read error: 104 (Connection reset by peer)) 01:25:25 --- quit: JasonWoof ("off to bed") 01:37:41 --- quit: warpzero (Remote closed the connection) 02:10:59 --- join: neceve (n=Clau@unaffiliated/neceve) joined #forth 02:24:33 --- join: granv (n=grahame@82-38-120-89.cable.ubr01.hali.blueyonder.co.uk) joined #forth 02:26:55 --- quit: granv (Remote closed the connection) 03:39:22 --- quit: alahzad (Read error: 104 (Connection reset by peer)) 04:45:14 --- join: PoppaVic (n=pete@0-1pool73-87.nas24.chicago4.il.us.da.qwest.net) joined #forth 04:57:30 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth 04:58:57 --- join: tathi_ (n=josh@c-68-81-250-189.hsd1.pa.comcast.net) joined #forth 04:59:01 --- quit: tathi_ (Client Quit) 06:30:40 --- join: Cheery (i=Henri@a81-197-45-47.elisa-laajakaista.fi) joined #forth 06:36:52 --- join: ravenEx (i=ravenEx@VPN-239-66.aichyna.com) joined #forth 06:43:06 hmm 06:54:48 --- join: ccfg (n=ccfg@dsl-roigw1-fe8ade00-21.dhcp.inet.fi) joined #forth 06:59:48 --- quit: PoppaVic ("Pulls the pin...") 07:01:47 --- join: PoppaVic (n=pete@0-1pool47-18.nas30.chicago4.il.us.da.qwest.net) joined #forth 07:46:42 --- join: PoppaVic1 (n=pete@0-2pool236-176.nas22.chicago4.il.us.da.qwest.net) joined #forth 07:46:55 --- quit: PoppaVic (Nick collision from services.) 07:47:03 --- nick: PoppaVic1 -> PoppaVic 08:02:44 --- quit: ravenEx (Read error: 145 (Connection timed out)) 08:27:42 hi 08:31:20 howdy 08:54:22 --- join: JasonWoof (n=jason@pdpc/supporter/student/Herkamire) joined #forth 08:54:22 --- mode: ChanServ set +o JasonWoof 09:02:54 --- join: Amanita_Virosa (n=jenni@adsl-69-154-178-250.dsl.hstntx.swbell.net) joined #forth 09:20:52 --- join: virl (n=virl@62.178.85.149) joined #forth 09:27:22 --- join: granv (n=grahame@82-38-120-89.cable.ubr01.hali.blueyonder.co.uk) joined #forth 09:29:11 --- quit: PoppaVic ("Pulls the pin...") 09:29:36 --- quit: granv (Remote closed the connection) 09:40:59 --- quit: Amanita_Virosa ("Wewwwp!") 09:47:18 --- join: LOOP-HOG (n=chatzill@sub22-119.member.dsl-only.net) joined #forth 10:57:30 --- join: PoppaVic (n=pete@0-1pool46-146.nas30.chicago4.il.us.da.qwest.net) joined #forth 10:58:17 --- join: Lars_G (n=lars@unaffiliated/lars-g/x-000001) joined #forth 11:36:59 --- join: warpzero (n=warpzero@wza.us) joined #forth 12:04:53 --- part: Lars_G left #forth 12:30:25 --- quit: PoppaVic ("Pulls the pin...") 12:33:17 *(&#$ #firefox*&#@@#u 12:33:37 I hit refresh on a page and it downloads the new stylesheet 12:33:49 I click to another page that uses that same stylesheet and it goes back to using the old one 12:34:06 why would it still even HAVE the old one 12:52:16 firefox is wacky like that. it's cacheing is detached from everything else and follows it's own rules. 13:55:26 --- quit: LOOP-HOG (Read error: 110 (Connection timed out)) 14:39:29 --- join: nballen (n=nballen@ppp-69-229-206-224.dsl.renocs.pacbell.net) joined #forth 14:45:52 arg! I can't figure out how to get stupid gnu binutils to dump PowerPC assembly from a pure binary. (it will decode some instruction but most stuff just shows up as .long). I'm using $(OBJDUMP) -b binary -m powerpc -D myfile.bin 14:46:15 hmm 14:47:14 --- quit: virl (Remote closed the connection) 14:47:18 00000000 <.data>: 0: 3c 40 e0 00 .long 0xe0403c 4: 60 42 45 00 .long 0x454260 8: 38 00 00 43 bdnz- 0x40 14:47:44 yeah, I see. 14:47:47 hrm. didn't paste well. but you see those. those are actually 'lis' and 'ori' instructions. 14:48:11 why does it understand bdnz but not something as basic as lis and ori. geez 14:50:48 hrm. I swear this used to work. 14:50:52 I don't know... 14:52:08 yea. i can't believe it's broken. it makes objdump work as well as a hexdump. 14:52:23 i think the key here is it thinks this is a .data section. when in reality it's .text 14:53:41 that would be my guess as well 14:55:23 i can view the elf format just fine. but... the branchs aren't resolved yet. and I'm pretty sure my bug is in my branch addresses (I think i don't have the address for these sections configured correctly yet) 14:56:43 although...it seems to work OK at disassembling the .data section of an ELF file... 14:56:52 very odd 14:57:18 ohhhh. 14:57:31 it thinks it's little-endian, I believe. 14:57:36 OHH 14:57:48 yup. 14:57:50 that works 14:58:15 -EB .. perfect 14:58:26 thanks. you're awesome:) 15:21:42 --- quit: Cheery ("Leaving") 15:24:31 --- quit: uiuiuiu (Remote closed the connection) 15:24:36 --- join: uiuiuiu (i=ian@dslb-084-056-233-236.pools.arcor-ip.net) joined #forth 15:38:47 --- quit: crc () 15:44:39 --- join: sersport (i=sergavr1@ts8-a3.Moscow.dial.rol.ru) joined #forth 15:45:08 hi 15:45:10 I live in Russia 15:45:28 hi sersport 15:54:05 hi 15:54:10 i live in germany 15:54:32 Berlin? 15:55:23 nope 15:55:27 near frankfurt 15:55:56 FC Eintracht 15:56:10 ^^ 15:56:22 football 15:57:48 --- join: crc (i=crc@pool-70-110-204-254.phil.east.verizon.net) joined #forth 15:59:38 --- part: sersport left #forth 16:08:36 --- quit: crc (Read error: 104 (Connection reset by peer)) 16:13:54 --- quit: nballen () 16:26:10 --- quit: Snoopy42 (Read error: 131 (Connection reset by peer)) 16:35:10 --- join: crc (i=crc@pool-70-110-138-7.phil.east.verizon.net) joined #forth 16:42:47 --- join: Snoopy42 (i=snoopy_1@dslb-084-058-140-050.pools.arcor-ip.net) joined #forth 16:45:33 --- quit: tathi ("leaving") 17:14:44 --- quit: neceve ("Bye people, I'm leaving") 17:45:46 --- join: amca (n=plump@as-bri-3-24.ozonline.com.au) joined #forth 17:49:17 crc: retroforth.net will now automagically redirect towards retroforth.org? 17:50:24 crc: The webpage is looking even better than last time I looked, too 17:51:26 crc: Except i tried http://retroforth.org/get/apps/aop-forth.tar.gz and got "403 Forbidden" 18:05:56 --- nick: Raystm2 -> tiff 18:37:20 amca: retroforth.com and retroforth.net should redirect to retroforth.org 18:37:22 hmm 18:37:51 you should be able to get it now; I had the permissions wrong 18:38:36 * crc is working on the native release of retroforth this week :) 18:40:55 how is it going? 18:42:34 pretty good; I have a basic vga driver in place; now working on some drawing primitives 18:43:06 cool :) which ones? 18:43:33 point, horizontal/vertical line, arbitrary line? 18:43:44 which modes will it support 18:43:45 ? 18:43:57 mode 13h and derivatives off that at present 18:44:05 * amca nods 18:44:37 vesa will require dropping to real mode to enable/disable, so I'm ignoring it at present 18:45:05 * amca nods 18:45:59 Are you planning to implement that later? Or will you, say, add higher res/lower number count vga modes? 18:46:31 I'm not totally sure yet 18:46:51 * amca nods 18:47:14 any drawing primitives I havent mentioned that you will add? 18:47:50 eventually boxes and circles 18:47:55 /me nods 18:47:59 oops :) 18:48:00 possibly roundrect 18:48:45 Might be an idea for circle to be a gspecific case of arc? 18:49:01 possibly 18:49:32 I tend to add/redo things often, so I may do a circle routine, then refactor arc out of it later; once I actually need it 18:49:58 * amca nods 18:51:08 the only real problem I have is the return to text mode 18:51:28 at this point, upon switching back, the screen gets filled with horizontal lines that can't be removed 18:51:40 hmm 18:51:47 do you have an idea why? 18:52:12 a) one of the registers is being recorded incorrectly 18:52:32 b) it's possible I'm corrupting a memory area 18:52:38 recorded incorrectly? 18:52:42 I tend to lean towards a) at this point 18:53:07 I use port i/o to probe the initial video register settings 18:53:21 I may have a value swapped, or written back in the wrong order 18:53:43 ah 18:54:15 so the interface between the video driver and the video controller might be a little confused? 18:54:18 it's a minor hassle really; once I have the drawing primitives; I can do a graphical console and not need to switch back 18:54:20 yeah 18:54:48 what res? 18:54:54 320x200? 18:55:04 at this point, yes 18:55:25 * amca nods 18:55:55 that mode can be tweaked up to 400x300, which is tolerable for a simple vga driver 18:56:30 the drawing stuff will all be generic, using a linear framebuffer. Whenever I get around to doing the vesa support, res will jump up cleanly 18:56:40 * amca nods 18:56:55 * crc explored vesa support years ago; this is a fresh start though 18:57:37 linear frame buffer as opposed to what? Are there non-linear frame buffers? 18:57:55 there are modes that use multiple planes 18:58:07 the plane approach is faster, but more difficult to work with 18:58:58 As in different colour planes? 18:59:06 like an r g and b plane? 18:59:26 no, a way of addressing the memory 18:59:42 with mode 13h, if you unchain it, you get 4 planes of 64k 19:00:06 and what do the different planes contain? 19:00:48 the first plane gets pixels 0, 4, 8, ... the second gets 1, 5, 9 ... the third gets 2, 6, 10, and the fourth gets 3, 7, 11 19:00:50 and so on 19:00:54 Ah 19:00:56 i see 19:00:56 it's a bit tricky 19:01:05 So the pixels are interleaved a bit 19:01:10 yup 19:01:17 makes the drawing primitives a bit more complex 19:01:19 where are you getting the docs/refs for this? 19:01:26 google :) 19:01:47 http://www.brackeen.com/home/vga/unchain.html has info on the unchained mode 13h 19:01:50 google isnt directing you to one site that has all this info about VGA controllers? 19:02:54 are you gonna do bufferring? 19:02:58 eventually 19:03:08 I haven't found a single site with everything on it 19:03:53 * amca nods 19:07:00 http://www.osdever.net/FreeVGA/home.htm has lots of good info 19:07:19 i was wondering: if unchained is faster, but chained is easier, would it be easier and faster to have the buffer as flat memory and have the buffer to video write function/word deal with the complexity of the planes, or would that not give any speed advantage compared to unchained? 19:07:31 I mean "compared to chained 19:07:31 " 19:07:33 I'm not sure 19:07:40 * amca nods 19:07:54 It would be something worth looking into 19:12:05 --- join: LOOP-HOG (n=chatzill@sub22-119.member.dsl-only.net) joined #forth 19:12:10 hi 19:12:16 are you using the bios at all for the driver, or directly using the controller? 19:12:18 Hi 19:12:58 directly controling the hardware 19:13:03 cool 19:13:11 * crc prefers to stay away from the 16-bit monster that is the PC BIOS 19:13:18 hehe 19:13:35 do you have on hand the url for where I could find the basic fundamentals of VGA control? 19:13:59 if it has anything to do with a PC, it's probably a monster, but heck, I"m not a real programmer, I'm just guessing. 19:14:12 what would I know? 19:15:13 LOOP-HOG: I dont know. What *do* you know? :D 19:15:31 http://home.worldonline.dk/finth/vgadoc4b.zip 19:15:38 this has some good, solid info 19:15:51 thanks :) 19:16:09 np 19:16:19 But I suspect that the PC didn't rise to dominance baised entirely on merit 19:16:58 PC is (*was) simple and fairly cheap to clone 19:17:53 Probably like most things, the popularity was due to economics and personal effort 19:19:50 Ataris and Amigas were better in their day 19:20:26 LOOP-HOG: why was that? 19:20:42 Flat addresses for example 19:20:47 * crc finds the x86 PC architecture tolerable; though it's getting harder to support as it gets more and more complex 19:20:49 Real sound and real graphics out of the box 19:21:01 cheaper 19:23:35 LOOP-HOG: Did Ataris and Amigas have 32 bit addressing? 19:23:41 yes 19:23:47 ah 19:23:59 nicer instruction set 19:24:07 Did they use Motorola chips? 19:24:07 68K 19:24:11 yes 19:24:13 * amca nods 19:24:14 LOOP-HOG: x86 is capable of flat addressing; I use that in my OS 19:24:32 back in 1988? 19:24:48 crc: you have to switch it into the 32 bit mode and set up address translation tables dont you? 19:25:02 LOOP-HOG: ok, you win there 19:25:03 386 came out in 86 or 88 didnt it? 19:25:18 amca: yes, pmode and a gdt; pretty trivial really 19:25:33 gdt? 19:25:40 general descriptor table? 19:25:47 global descriptor table 19:25:53 ah 19:26:01 actually, 386 was in 1986 19:26:09 so, yes, in 1988 ;) 19:26:35 MS was just very slow in having the SW use the hardwares capabilities 19:26:41 Usually that way 19:26:48 yeah 19:26:59 They both had a mouse and a GUI out of the box 19:27:08 * crc still codes for the 386 19:27:26 LOOP-HOG: the software != hardware platform 19:27:33 unfortuately they were 10x more difficult to program for than the 8bit Atair and Commadores 19:27:43 LOOP-HOG: How come? 19:28:01 Ok, the Atari was, maybe not the Amiga 19:28:03 I'm thinking of the PC as a hardware platform; I can do the software myself for the most part 19:28:08 To do much you had to go through the GUI 19:28:22 No special hardware for graphics, everything was bitmaped 19:29:23 LOOP-HOG: Did you/the OS have to set up tables for Atari/Amiga to operate on 32 bits of memory properly? 19:29:37 amca, no 19:30:10 crc: What is the advantage of gdt's? 19:30:13 did the Atari/Amiga support non-flat modes of addressing 19:30:24 amca: flexibility; you can setup memory in many different ways 19:31:03 no 19:31:14 crc: Such as? 19:31:30 paged, segmented, linear at a minimum 19:31:41 I've not explored any other models 19:32:06 what is the advantage of paged memory? why not just stick with linear? 19:32:07 also, you can mix them: 4gb segments are possible on a 386 in real mode using a custom gdt 19:32:20 pages make virtual memory significantly easier 19:32:26 and allow for memory protection 19:34:00 * amca nods 19:34:17 And what are the advantages of segmentation compared to flat and paged? 19:34:18 I personally just use a linear memory model; it's the cleanest IMO 19:34:25 Not much 19:34:33 * amca nods 19:34:41 you get more control of the sizes of segments 19:34:54 pages are mostly limited to being 4k in size 19:35:20 ah 19:35:34 also, you can setup different segments for a programs data, code, and other areas, and also the stack 19:36:00 * amca nods 19:45:20 crc: can you tell in sw what controller chip is being used easily? Do you have to compensate for different controller chips much? 19:46:00 I'm using mode 13h which every vga compatible card should support 19:46:37 * amca nods 19:48:09 --- nick: tiff -> Raystm2 19:48:22 hello Ray 19:48:33 Hi Charles, good day? 19:48:39 yes 19:48:50 Great, me too. Overtime still? 19:48:51 Hi Ray 19:48:59 Raystm2: always 19:49:04 amca!! How are you? 19:49:15 I have low-res vga working nicely now :) 19:49:15 crc: ya me too. seems like always. 19:49:21 pretty okay currently for a change :) 19:49:30 Raystm2: How are you? 19:49:48 * Raystm2 is doing fine. 19:50:05 So busy at work I don't even have time to go to my part-time job anymore. 19:50:46 crc: low-res vga? what like 320x??? or something? 19:50:55 320x200, 256 colors 19:51:12 I'll be able to tweak that to 400x300 sometime soon I think 19:51:13 cool I got one number out of 3 right! :) 19:51:17 that's very cool. 19:51:44 that means you have graphics now? 19:51:59 heck plenty for colorforth. 19:52:02 basically yes 19:52:29 just have to scroll the screen for colorforth at that res, I suppose. 19:52:32 I'm doing the drawing primitives now; once that's done, all I have left to do is a font display and graphics will be functional 19:52:48 Bass ad. 19:52:50 not necessarily; just scale things down to fit :) 19:52:54 :) 19:52:55 ya 19:53:40 : put-pixel 320 * + $a0000 + c! ; 19:53:56 that's the core drawing primitive :) 19:54:05 no kidding, neat. 19:54:18 a0000 = display frame buffer? 19:54:29 $a0000 even 19:54:39 yup 19:55:05 and 320 = offset in the buffer or no your scaling something by 320. 19:55:43 so put-pixel takes 3 items on the stack? 19:55:53 320 = calculate 'y' offset 19:55:54 yes 19:55:58 ( color x y -- ) 19:56:09 ok 19:56:47 okay y is like the line number, per se. 19:57:07 0 = top line, 1 is the line under that... 19:57:08 yeah 19:57:27 x = how far down that line. 19:57:48 are you going from top or bottom for y=0 19:58:26 top 19:58:32 very cool. 20:00:46 c! takes the calculated xy as an offset to the display buffer and then stores the color ( rgb? someother value?) at that location in the buffer. 20:00:57 yes 20:01:05 oh wait that's character-Store so that means bytes 20:01:09 the color is a byte representing a color in the palette 20:01:13 right 20:01:20 mode 13h uses one byte per pixel 20:01:23 ah the pallet 20:01:25 so 256 colors 20:01:42 the pallette can have over 200,000 colors in it; but only 256 active at a time 20:01:48 I see. 20:01:54 you can swap pallets? 20:02:00 yes 20:02:09 do you define that pallet or is that part of the mode? 20:02:25 I'm using the default pallette 20:02:50 so that's part of the mode then? but sounds like you can swap your own in if you want. 20:03:14 yes 20:03:19 Oh wait, are pallets some offset from $a0000. 20:03:21 ? 20:03:37 pallets are in video registers arent htey? 20:08:09 crc; Have you considered Mode X? 20:08:11 hehe the only pallets that i have intimate knowledge about are 48x40inches and you should never stack one more then 7 feet high or with more then 3000lbs of product or no-one can physically handleit. 20:08:20 lol 20:08:50 's modeX? 20:09:44 320 x 240 20:09:57 256 colours 20:10:05 oh more chars per line then? 20:10:24 More lines of pixels 20:10:25 well pixels anyway. 20:10:31 oh more lines 20:10:55 i thought it would be easier to code for, as it has 4:3 ratio whereas 320x200 doesnt and so makes aspet more complex for circles etc 20:11:38 modeX is unchained, so it has the planes to deal with 20:11:44 ah 20:12:18 I can add support for that once I get the basics done though; I think I have a way to take care of it :) 20:12:24 it'll be slow though 20:13:34 what is the way to take care of it? 20:15:13 I'll add an update word that takes a linear buffer and tranlates it to the chains and updates the screen 20:15:21 the drawing words will call this at the end 20:15:34 (for true linear modes, it'll be devectored and do nothing) 20:16:02 kinda what I said about the buffering? 20:16:11 yeah, that gave me the idea 20:16:28 when I add multitasking, it could become a background task, but that's quite a ways off 20:16:58 * amca nods 20:17:30 I updated the iso to include put-pixel and the working vga bits 20:18:35 Is it tarballed? 20:18:55 the source? 20:18:59 or the iso? 20:19:10 nvm I was getting ahead of myself 20:19:48 iso = image? 20:19:53 mmm, the compressed iso is 64k; the uncompressed one is 484k 20:19:55 CD image 20:19:57 Raystm2: cd image 20:20:04 crc: That is HUGE! ;) 20:20:14 most of that is GRUB 20:20:47 the retro kernel+drivers is about 20k 20:21:30 hehe 20:22:19 mostly ascii source 20:23:25 10330 bytes of ascii source compiled during bootstrap 20:23:49 about 2-2.5k for the kernel; the rest is the assembly for hard disk and console support 20:24:03 much of the hard disk and console support will become ascii source over time 20:25:23 * amca nods 20:25:37 Leaving the core to basic IO and specific IO to source 20:25:54 actually, the core contains as little asm as possible for most ports 20:26:46 --- part: crc left #forth 20:26:49 --- join: crc (i=crc@pool-70-110-138-7.phil.east.verizon.net) joined #forth 20:27:04 wb 20:27:07 heh 20:27:14 closed the wrong tab 20:27:42 i've done that. 20:29:17 iso's are at http://retroforth.org/get/extras if anyone wants to try it 20:29:30 I set a variable 'ink' to hold the current color 20:29:58 tomorrow I'll work on support for drawing lines :) 20:30:17 crc: What? "ink"? What an arbitrary name! Why didnt you call it "ojg"? ;P 20:38:50 crc: glad to hear about the progress with rf :) 20:40:18 is it 9.0.2 ver? 20:40:24 9.1-beta 20:40:36 tnx 20:40:53 np 20:41:31 why is 9.0.2 labelled 900 instead of 9002 or 902? 20:42:18 I only track the major/minor version internally 20:42:55 the .2 is the number of bugfix releases since the last minor release; it's not that significant 20:42:57 why is that? 20:43:04 ok 20:43:28 what does :: mean? 20:43:31 no compatibility changes are made to a release; so 9.0.x is all compatible 20:43:36 :: is like :noname in ANS 20:43:49 cool. i thought it might be that 20:43:55 i see 20:44:40 most of the words are covered at http://retroforth.org/doc/handbook/retroforth/ 20:44:48 * amca nods 20:45:12 Ive downloaded it too, i just was too lazy to look it up as it was the only word I was confused by 20:45:17 i have to get to bed; work in the morning :( 20:45:20 cool 20:45:25 Have a good sleep 20:45:30 goodnight everyone 20:46:48 time for me to attend to work. Farewell 20:46:51 --- quit: amca ("d34d") 20:54:21 --- join: Teratogen (i=leontopo@intertwingled.net) joined #forth 20:57:35 good night crc. 23:26:21 --- quit: LOOP-HOG ("ChatZilla 0.9.61 [Mozilla rv:1.7.5/20041217]") 23:59:59 --- log: ended forth/06.03.14