From dseagrav@lunar-tokyo.net Mon Dec 5 10:38:08 2005 From: dseagrav@lunar-tokyo.net (Daniel Seagraves) Date: Mon, 5 Dec 2005 04:38:08 -0600 (CST) Subject: [LMH] Lisp timing issue solved In-Reply-To: <20051128224603.191B518982@tech.vm.bytemark.co.uk> References: <20051128224603.191B518982@tech.vm.bytemark.co.uk> Message-ID: I solved the Lisp timing bug. Fixing this enables lisp to keep proper time, boot with a network card, and causes the mouse to work. The clue was that setting the retrace-interval timer to it's correct value caused a crash. On further investigation, lisp was writing the Interval 0 count while the interval timer was in latched-read mode, THEN crashing. In my code that wasn't anticipated and ended up being a no-op. Lisp is trying to count the refresh rate. I made writing in latched-read mode operate like writing in MSB/LSB mode, and lisp works now. Lisp is trying to check the refresh rate. The rate of the 100MS/10MS/100NS RTC clocks are checked also, failing the checks doesn't cause lisp to crash but causes it to disable most of the SIB, which creates the odd behaviour we were seeing. I still haven't solved the keyboard repeating bug. Timing doesn't seem to affect it. From nyef@lisphacker.com Mon Dec 5 15:29:48 2005 From: nyef@lisphacker.com (nyef@lisphacker.com) Date: Mon, 05 Dec 2005 15:29:48 +0000 Subject: [LMH] Lisp timing issue solved In-Reply-To: References: <20051128224603.191B518982@tech.vm.bytemark.co.uk> Message-ID: <20051205152948.80DEA18737@tech.vm.bytemark.co.uk> Daniel Seagraves writes: > I solved the Lisp timing bug. Fixing this enables lisp to keep proper > time, boot with a network card, and causes the mouse to work. Assuming, of course, that you have mouse emulation in the first place. ^_- Congratulations, though. > I still haven't solved the keyboard repeating bug. Timing doesn't seem to > affect it. I'd wonder if it has more to do with the frequency at which you check for keyboard events than with any of the lisp-side timing stuff? --Alastair Bridgewater From dseagrav@lunar-tokyo.net Mon Dec 5 17:09:25 2005 From: dseagrav@lunar-tokyo.net (Daniel Seagraves) Date: Mon, 5 Dec 2005 11:09:25 -0600 (CST) Subject: [LMH] File bands In-Reply-To: <20051205152948.80DEA18737@tech.vm.bytemark.co.uk> References: <20051128224603.191B518982@tech.vm.bytemark.co.uk> <20051205152948.80DEA18737@tech.vm.bytemark.co.uk> Message-ID: Does anyone know how to change file bands or read the contents of the other one? The sys-intro manual says to read the I/O reference, but we don't have it. From dseagrav@lunar-tokyo.net Mon Dec 5 17:10:27 2005 From: dseagrav@lunar-tokyo.net (Daniel Seagraves) Date: Mon, 5 Dec 2005 11:10:27 -0600 (CST) Subject: [LMH] Lisp timing issue solved In-Reply-To: <20051205152948.80DEA18737@tech.vm.bytemark.co.uk> References: <20051128224603.191B518982@tech.vm.bytemark.co.uk> <20051205152948.80DEA18737@tech.vm.bytemark.co.uk> Message-ID: On Mon, 5 Dec 2005 nyef@lisphacker.com wrote: > I'd wonder if it has more to do with the frequency at which you check for > keyboard events than with any of the lisp-side timing stuff? It might be. Inserting delays between key down and up events doesn't seem to help; I'll screw around with the timing and see what I get. From Bjorn@Victor.se Mon Dec 5 17:19:46 2005 From: Bjorn@Victor.se (=?ISO-8859-1?Q?Bj=F6rn_Victor?=) Date: Mon, 05 Dec 2005 18:19:46 +0100 Subject: [LMH] Lisp timing issue solved In-Reply-To: References: <20051128224603.191B518982@tech.vm.bytemark.co.uk> <20051205152948.80DEA18737@tech.vm.bytemark.co.uk> Message-ID: <439476B2.5000206@Victor.se> This is a multi-part message in MIME format. --------------010508050306010704020507 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Daniel Seagraves wrote: > On Mon, 5 Dec 2005 nyef@lisphacker.com wrote: >=20 >=20 >>I'd wonder if it has more to do with the frequency at which you check f= or >>keyboard events than with any of the lisp-side timing stuff? >=20 >=20 > It might be. Inserting delays between key down and up events doesn't se= em > to help; I'll screw around with the timing and see what I get. Actually I think it was just the keymap which was screwed up, so Lisp didn't see keys coming up correctly. I cleaned up the code just a little, mostly in order to understand it better (attached, including fixes to initialize the RTC so Lisp gets the right time). Anyway, it seems to work better for me. YMMV? -- Bj=F6rn --------------010508050306010704020507 Content-Type: text/plain; name="sib.c.patch.2" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="sib.c.patch.2" *** sib.c.~1~ 2005-12-05 13:06:07.000000000 +0100 --- sib.c 2005-12-05 18:16:55.000000000 +0100 *************** *** 26,31 **** --- 26,34 ---- #include #include #endif + #ifdef DISPLAY_SDL + #include + #endif // Set host framebuffer resolution here #ifndef FB_WIDTH *************** *** 248,253 **** --- 251,279 ---- // **** NEW RTC / ITIMER CODE **** + unsigned char dec_to_bcd(int n) { + return (((((n)/10)&0xf)<<4)|(((n)%10)&0xf)); + } + void + sib_rtc_initialize() + { + time_t tnow = time(NULL); + struct tm *now = localtime(&tnow); + + sib_rtc_sec = dec_to_bcd(now->tm_sec); + sib_rtc_min = dec_to_bcd(now->tm_min); + sib_rtc_hour = dec_to_bcd(now->tm_hour); + sib_rtc_dow = dec_to_bcd(now->tm_wday); + if (now->tm_mon == 1 && now->tm_mday == 29) + sib_rtc_date = dec_to_bcd(now->tm_mday-1); + else + sib_rtc_date = dec_to_bcd(now->tm_mday); + sib_rtc_month = sib_ram_month = dec_to_bcd(now->tm_mon+1); + /* Hack */ + sib_ram_10ms = dec_to_bcd((now->tm_year)%100); + sib_ram_100ns = (((now->tm_year/100))<<5) | (((now->tm_mon == 1 && now->tm_mday == 29)&1)<<4); + } + void sib_updateslow(){ // Add a second sib_rtc_sec++; *************** *** 374,470 **** init_sdl_to_keysym_map(void) { map[0x12] = 1; ! map['1'] = 0x24a4; // 1 ! map['2'] = 0x25a5; // 2 ! map['3'] = 0x26a6; // 3 ! map['4'] = 0x27a7; // 4 ! map['5'] = 0x28a8; // 5 ! map['6'] = 0x29a9; // 6 ! map['7'] = 0x2aaa; // 7 ! map['8'] = 0x2bab; // 8 ! map['9'] = 0x2cac; // 9 ! map['0'] = 0x2dad; // 0 ! map['-'] = 0x2eae; // - ! map['+'] = 0x2faf; // + ! ! map['Q'] = 0x39b9; // Q ! map['W'] = 0x3aba; // W ! map['E'] = 0x3bbb; // E ! map['R'] = 0x3cbc; // R ! map['T'] = 0x3dbd; // T ! map['Y'] = 0x3ebe; // Y ! map['U'] = 0x3fbf; // U ! map['I'] = 0x40c0; // I ! map['O'] = 0x41c1; // O ! map['P'] = 0x42c2; // P ! ! map['A'] = 0x50d0; // A ! map['S'] = 0x51d1; // S ! map['D'] = 0x52d2; // D ! map['F'] = 0x53d3; // F ! map['G'] = 0x54d4; // G ! map['H'] = 0x55d5; // H ! map['J'] = 0x56d6; // J ! map['K'] = 0x57d7; // K ! map['L'] = 0x58d8; // L ! ! map['Z'] = 0x68e8; // Z ! map['X'] = 0x69e9; // X ! map['C'] = 0x6aea; // C ! map['V'] = 0x6beb; // V ! map['B'] = 0x6cec; // B ! map['N'] = 0x6ded; // N ! map['M'] = 0x6eee; // M ! ! map['['] = 0x43c3; ! map[']'] = 0x1b9b; ! map[';'] = 0x27a7; ! map['~'] = 0x29a9; // TILDE - MAPS TO SYMBOL ! map['\\'] = 0x46c6; ! map[' '] = 0x7bfb; ! map[','] = 0x6fef; ! map['.'] = 0x70f0; map['/'] = 0x71fa; ! map[';'] = 0x59d9; ! map['\''] = 0x5ada; ! map['='] = 0x32b2; ! map['+'] = 0x33b3; ! map[0x0d] = 0x5bdb; // ENTER ! map[0x08] = 0x4fcf; // BACKSPACE (MAPS TO RUBOUT) ! map[0x09] = 0x35b5; // TAB ! map[0x1b] = 0x23a3; // ESC ! ! map[273] = 0x47c7; // up arrow ! map[274] = 0x75f5; // down arrow ! map[275] = 0x5fdf; // right arrow ! map[276] = 0x5ddd; // left arrow ! map[277] = 0x1595; /* HOME - F1 */ ! map[278] = 0x1494; /* INSERT - F2 */ ! ! map[280] = 0x76f6; /* PAGEUP - ABORT */ ! ! map[282] = 0x0888; /* F1 - SYSTEM */ ! map[283] = 0x0989; /* F2 - NETWORK */ ! map[284] = 0x0a8a; /* F3 - STATUS */ ! map[285] = 0x0b8b; /* F4 - TERMINAL */ ! map[286] = 0x0181; /* F5 - HELP */ ! ! map[301] = 0x0383; // CAPSLOCK ! ! map[303] = 0x67e7; // RIGHT SHIFT ! map[304] = 0x72f2; // LEFT SHIFT ! map[303] = 0xe767; // RIGHT SHIFT ! map[304] = 0xf272; // LEFT SHIFT ! map[305] = 0x1c9c; // RIGHT CTRL ! map[306] = 0x1c9c; // LEFT CTRL ! map[307] = 0x1b9b; // RIGHT ALT (META) ! map[308] = 0x1b9b; // LEFT ALT (META) - map[311] = 0x1a9a; // RIGHT windows (SUPER) - map[312] = 0x1a9a; // LEFT windows (SUPER) } unsigned char lastchar=0; --- 400,501 ---- init_sdl_to_keysym_map(void) { map[0x12] = 1; ! map['1'] = 0x24; // 1 ! map['2'] = 0x25; // 2 ! map['3'] = 0x26; // 3 ! map['4'] = 0x27; // 4 ! map['5'] = 0x28; // 5 ! map['6'] = 0x29; // 6 ! map['7'] = 0x2a; // 7 ! map['8'] = 0x2b; // 8 ! map['9'] = 0x2c; // 9 ! map['0'] = 0x2d; // 0 ! map['-'] = 0x2e; // - ! map['+'] = 0x2f; // + ! ! map['Q'] = 0x39; // Q ! map['W'] = 0x3a; // W ! map['E'] = 0x3b; // E ! map['R'] = 0x3c; // R ! map['T'] = 0x3d; // T ! map['Y'] = 0x3e; // Y ! map['U'] = 0x3f; // U ! map['I'] = 0x40; // I ! map['O'] = 0x41; // O ! map['P'] = 0x42; // P ! ! map['A'] = 0x50; // A ! map['S'] = 0x51; // S ! map['D'] = 0x52; // D ! map['F'] = 0x53; // F ! map['G'] = 0x54; // G ! map['H'] = 0x55; // H ! map['J'] = 0x56; // J ! map['K'] = 0x57; // K ! map['L'] = 0x58; // L ! ! map['Z'] = 0x68; // Z ! map['X'] = 0x69; // X ! map['C'] = 0x6a; // C ! map['V'] = 0x6b; // V ! map['B'] = 0x6c; // B ! map['N'] = 0x6d; // N ! map['M'] = 0x6e; // M ! ! map['['] = 0x43; ! map[']'] = 0x1b; ! map[';'] = 0x27; ! map['~'] = 0x29; // TILDE - MAPS TO SYMBOL ! map['\\'] = 0x46; ! map[' '] = 0x7b; ! map[','] = 0x6f; ! map['.'] = 0x70; map['/'] = 0x71fa; ! map[';'] = 0x59; ! map['\''] = 0x5a; ! ! map['='] = 0x32; ! map['+'] = 0x33; ! map[SDLK_RETURN] = 0x5b; // ENTER ! map[SDLK_BACKSPACE] = 0x4f; // BACKSPACE (MAPS TO RUBOUT) ! map[SDLK_TAB] = 0x35; // TAB ! map[SDLK_ESCAPE] = 0x23; // ESC ! ! map[SDLK_UP] = 0x47; // up arrow ! map[SDLK_DOWN] = 0x75; // down arrow ! map[SDLK_RIGHT] = 0x5f; // right arrow ! map[SDLK_LEFT] = 0x5d; // left arrow ! map[SDLK_HOME] = 0x15; /* HOME - F1 */ ! map[SDLK_INSERT] = 0x14; /* INSERT - F2 */ ! ! map[SDLK_PAGEUP] = 0x4c; /* PAGEUP - ABORT */ ! map[SDLK_PAGEDOWN] = 0x21; /* PAGEDOWN - RESUME */ ! ! map[SDLK_F1] = 0x08; /* F1 - SYSTEM */ ! map[SDLK_F2] = 0x09; /* F2 - NETWORK */ ! map[SDLK_F3] = 0x0a; /* F3 - STATUS */ ! map[SDLK_F4] = 0x0b; /* F4 - TERMINAL */ ! map[SDLK_F5] = 0x01; /* F5 - HELP */ ! map[SDLK_F6] = 0x0e; /* F6 - Clear Input */ ! ! map[SDLK_CAPSLOCK] = 0x03; // CAPSLOCK ! ! map[SDLK_RSHIFT] = 0x67e7; // RIGHT SHIFT ! map[SDLK_LSHIFT] = 0x72f2; // LEFT SHIFT ! #if 1 ! map[SDLK_RSHIFT] = 0xe767; // RIGHT SHIFT ! map[SDLK_LSHIFT] = 0xf272; // LEFT SHIFT ! #endif ! map[SDLK_RCTRL] = 0x1c; // RIGHT CTRL ! map[SDLK_LCTRL] = 0x1c; // LEFT CTRL ! map[SDLK_RALT] = 0x1b; // RIGHT ALT (META) ! map[SDLK_LALT] = 0x1b; // LEFT ALT (META) ! map[SDLK_RSUPER] = 0x1a; // RIGHT windows (SUPER) ! map[SDLK_LSUPER] = 0x1a; // LEFT windows (SUPER) } unsigned char lastchar=0; *************** *** 497,503 **** if (sdlchar >= 'a' && sdlchar <= 'z') sdlchar -= ' '; ! outchar = down ? (map[sdlchar] >> 8) : (map[sdlchar] & 0xff); if (outchar == 0) { logmsgf("Keystroke lost (%x) - unmapped keycode\n", sdlchar); --- 528,537 ---- if (sdlchar >= 'a' && sdlchar <= 'z') sdlchar -= ' '; ! if (down && map[sdlchar] > 0xff) ! outchar = map[sdlchar] >> 8; ! else ! outchar = map[sdlchar] | (down ? 0x80 : 0); if (outchar == 0) { logmsgf("Keystroke lost (%x) - unmapped keycode\n", sdlchar); *************** *** 908,913 **** --- 942,950 ---- keyboard_usart_rx_fifo[0]=0; keyboard_usart_rx_bot=0; keyboard_usart_rx_top=0; + + sib_rtc_initialize(); + /* CONSOLE SETUP */ // Arrange for SIGIO on IO availability signal(SIGIO,kbdhandler); *************** *** 1191,1206 **** printf("Mouse initialization completed.\n"); #endif - // Clear screen and VRAM - bzero(framebuffer,screensize); - bzero(VRAM,0x20000); - #ifdef DISPLAY_SDL { ! extern void sdl_init(unsigned long int *ps, char **pfb); ! sdl_init(&screensize, &framebuffer); } #endif } void redraw_display(){ --- 1228,1243 ---- printf("Mouse initialization completed.\n"); #endif #ifdef DISPLAY_SDL { ! extern void sdl_init(unsigned long int *ps, char **pfb, int width, int height); ! sdl_init(&screensize, &framebuffer, FB_WIDTH, FB_HEIGHT); } #endif + // Clear screen and VRAM + bzero(framebuffer,screensize); + bzero(VRAM,0x20000); + } void redraw_display(){ *************** *** 1777,1783 **** case 0xF20000: // Mouse Y-Position Register case 0xF20001: // Mouse Y-Position Register, low-halfword mode NUbus_Data = sib_mouse_y_pos&0xFFFF; ! // logmsgf("READ MOUSE Y POS - 0x%lX\n",NUbus_Data); NUbus_acknowledge=1; sib_mouse_moved_sent = 0; return; --- 1814,1820 ---- case 0xF20000: // Mouse Y-Position Register case 0xF20001: // Mouse Y-Position Register, low-halfword mode NUbus_Data = sib_mouse_y_pos&0xFFFF; ! //logmsgf("READ MOUSE Y POS - 0x%lX\n",NUbus_Data); NUbus_acknowledge=1; sib_mouse_moved_sent = 0; return; *************** *** 1785,1791 **** case 0xF20005: // Mouse X-Position Register, low-halfword mode NUbus_Data = sib_mouse_x_pos&0xFFFF; NUbus_acknowledge=1; ! // logmsgf("READ MOUSE X POS - 0x%lX\n",NUbus_Data); sib_mouse_moved_sent = 0; return; case 0xF20008: // Mouse Keyswitch/Motion Data Register --- 1822,1828 ---- case 0xF20005: // Mouse X-Position Register, low-halfword mode NUbus_Data = sib_mouse_x_pos&0xFFFF; NUbus_acknowledge=1; ! //logmsgf("READ MOUSE X POS - 0x%lX\n",NUbus_Data); sib_mouse_moved_sent = 0; return; case 0xF20008: // Mouse Keyswitch/Motion Data Register *************** *** 1812,1818 **** }else{ // Otherwise, just return the register intact. NUbus_Data = sib_mouse_motion_reg; ! // logmsgf("READ MOUSE MOTION REG - 0x%lX\n",NUbus_Data); } } NUbus_acknowledge=1; --- 1849,1855 ---- }else{ // Otherwise, just return the register intact. NUbus_Data = sib_mouse_motion_reg; ! //logmsgf("READ MOUSE MOTION REG - 0x%lX\n",NUbus_Data); } } NUbus_acknowledge=1; *************** *** 1873,1878 **** --- 1910,1923 ---- NUbus_Data = sib_vox_data_reg&0xFFFF; NUbus_acknowledge=1; return; + case 0xF80000: + NUbus_Data = sib_rtc_100ns; + NUbus_acknowledge=1; + return; + case 0xF80004: + NUbus_Data = sib_rtc_10ms; + NUbus_acknowledge=1; + return; case 0xF80008: NUbus_Data = sib_rtc_sec; NUbus_acknowledge=1; *************** *** 1899,1910 **** return; case 0xF80020: NUbus_Data = sib_ram_100ns; ! logmsgf("SIB: RAM 100NS RD: %X\n",sib_ram_100ns); NUbus_acknowledge=1; return; case 0xF80024: NUbus_Data = sib_ram_10ms; ! logmsgf("SIB: RAM 10MS RD: %X\n",sib_ram_10ms); NUbus_acknowledge=1; return; case 0xF80050: // RTC Update Status Bit --- 1944,1979 ---- return; case 0xF80020: NUbus_Data = sib_ram_100ns; ! //logmsgf("SIB: RAM 100NS RD: %X\n",sib_ram_100ns); NUbus_acknowledge=1; return; case 0xF80024: NUbus_Data = sib_ram_10ms; ! //logmsgf("SIB: RAM 10MS RD: %X\n",sib_ram_10ms); ! NUbus_acknowledge=1; ! return; ! case 0xF80028: ! NUbus_Data = sib_ram_sec; ! NUbus_acknowledge=1; ! return; ! case 0xF8002C: ! NUbus_Data = sib_ram_min; ! NUbus_acknowledge=1; ! return; ! case 0xF80030: ! NUbus_Data = sib_ram_hour; ! NUbus_acknowledge=1; ! return; ! case 0xF80034: ! NUbus_Data = sib_ram_dow; ! NUbus_acknowledge=1; ! return; ! case 0xF80038: ! NUbus_Data = sib_ram_date; ! NUbus_acknowledge=1; ! return; ! case 0xF8003C: /* This one is essential */ ! NUbus_Data = sib_ram_month; NUbus_acknowledge=1; return; case 0xF80050: // RTC Update Status Bit *************** *** 2060,2070 **** --- 2129,2149 ---- NUbus_acknowledge=1; return; + case 0xF80000: // RTC 100ns counter + NUbus_Data = sib_rtc_100ns&0xFF; + // logmsgf("SIB: RTC 100NS RD: %X\n",sib_rtc_10ms); + NUbus_acknowledge=1; + return; case 0xF80004: // RTC 10ms counter NUbus_Data = sib_rtc_10ms&0xFF; // logmsgf("SIB: RTC 10MS RD: %X\n",sib_rtc_10ms); NUbus_acknowledge=1; return; + case 0xF80008: // RTC sec counter + NUbus_Data = sib_rtc_sec; + // logmsgf("SIB: sec RD: %X\n",sib_rtc_sec); + NUbus_acknowledge=1; + return; case 0xF8000C: // RTC 1min counter NUbus_Data = sib_rtc_min; NUbus_acknowledge=1; *************** *** 2087,2098 **** return; case 0xF80020: NUbus_Data = sib_ram_100ns; ! logmsgf("SIB: RAM 100NS RD: %X\n",sib_ram_100ns); NUbus_acknowledge=1; return; case 0xF80024: NUbus_Data = sib_ram_10ms; ! logmsgf("SIB: RAM 10MS RD: %X\n",sib_ram_10ms); NUbus_acknowledge=1; return; case 0xF80028: --- 2166,2177 ---- return; case 0xF80020: NUbus_Data = sib_ram_100ns; ! //logmsgf("SIB: RAM 100NS RD: %X\n",sib_ram_100ns); NUbus_acknowledge=1; return; case 0xF80024: NUbus_Data = sib_ram_10ms; ! //logmsgf("SIB: RAM 10MS RD: %X\n",sib_ram_10ms); NUbus_acknowledge=1; return; case 0xF80028: *************** *** 2524,2530 **** return; case 0xF80024: sib_ram_10ms = NUbus_Data&0xFF; ! logmsgf("SIB: RAM 10MS WT: %X\n",sib_ram_10ms); NUbus_acknowledge=1; return; case 0xF80028: --- 2603,2609 ---- return; case 0xF80024: sib_ram_10ms = NUbus_Data&0xFF; ! //logmsgf("SIB: RAM 10MS WT: %X\n",sib_ram_10ms); NUbus_acknowledge=1; return; case 0xF80028: *************** *** 3053,3059 **** return; case 0xF80024: sib_ram_10ms = NUbus_Data; ! logmsgf("SIB: RAM 10MS WT: %X\n",sib_ram_10ms); NUbus_acknowledge=1; return; case 0xF80028: --- 3132,3138 ---- return; case 0xF80024: sib_ram_10ms = NUbus_Data; ! //logmsgf("SIB: RAM 10MS WT: %X\n",sib_ram_10ms); NUbus_acknowledge=1; return; case 0xF80028: --------------010508050306010704020507-- From brad@heeltoe.com Mon Dec 5 17:39:24 2005 From: brad@heeltoe.com (Brad Parker) Date: Mon, 05 Dec 2005 12:39:24 -0500 Subject: [LMH] Lisp timing issue solved In-Reply-To: Message from =?ISO-8859-1?Q?Bj=F6rn_Victor?= of "Mon, 05 Dec 2005 18:19:46 +0100." <439476B2.5000206@Victor.se> Message-ID: <200512051739.jB5HdOWi029315@mwave.heeltoe.com> =?ISO-8859-1?Q?Bj=F6rn_Victor?= wrote: > >Actually I think it was just the keymap which was screwed up, so Lisp >didn't see keys coming up correctly. I cleaned up the code just a >little, mostly in order to understand it better (attached, including >fixes to initialize the RTC so Lisp gets the right time). > >Anyway, it seems to work better for me. YMMV? I tried Bjorn's patch and it worked really well for me. Looks like the machine somehow managed to find the data & time also (which is great!) should I apply it? I fumbled along for a while before I managed to halt at 81. I didn't see any keyboard problems. Things actually seem to be working pretty well. I could not get the mouse to work at all, however - no doubt an SDL problem. And the SDL window is *huge* - was it always that way? What's the correct window size it really wants? (daniel - I could swear you sent me email about that over the weekend but I can't find it - blah) -brad From dseagrav@lunar-tokyo.net Mon Dec 5 17:55:03 2005 From: dseagrav@lunar-tokyo.net (Daniel Seagraves) Date: Mon, 5 Dec 2005 11:55:03 -0600 (CST) Subject: [LMH] Lisp timing issue solved In-Reply-To: <200512051739.jB5HdOWi029315@mwave.heeltoe.com> References: <200512051739.jB5HdOWi029315@mwave.heeltoe.com> Message-ID: On Mon, 5 Dec 2005, Brad Parker wrote: > I tried Bjorn's patch and it worked really well for me. Looks like the > machine somehow managed to find the data & time also (which is great!) > > should I apply it? Hang on. I'll check in the time/date part (I already added it) but I haven't added the SDL code. Fire away. Did you comment out the extra 0 sent on key release? (I don't know if it applies to the SDL keyboard...) > I fumbled along for a while before I managed to halt at 81. I didn't > see any keyboard problems. Things actually seem to be working pretty > well. When lisp halts, the running function and such is written to NVRAM. (REPORT-LAST-SHUTDOWN) will read the data out. It always halts at 81, that's the end of the fault handler. > I could not get the mouse to work at all, however - no doubt an SDL > problem. And the SDL window is *huge* - was it always that way? What's > the correct window size it really wants? The Explorer's display is 1024x808, but I was using 1280x1024. I fixed the SIB so it can use other framebuffer sizes; Just make sure that FB_WIDTH and FB_HEIGHT are defined to whatever SDL window size you end up using. (If they are undefined, 1280x1024 is the default). Those two symbols are the width and height of the host display, not the Explorer display. (The explorer VRAM is 1024x1024 though - That's why screenshots have the extra space at the bottom.) From Bjorn@Victor.se Mon Dec 5 17:53:03 2005 From: Bjorn@Victor.se (=?ISO-8859-1?Q?Bj=F6rn_Victor?=) Date: Mon, 05 Dec 2005 18:53:03 +0100 Subject: [LMH] Lisp timing issue solved In-Reply-To: <200512051739.jB5HdOWi029315@mwave.heeltoe.com> References: <200512051739.jB5HdOWi029315@mwave.heeltoe.com> Message-ID: <43947E7F.30004@Victor.se> This is a multi-part message in MIME format. --------------010702030202080807090605 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Brad Parker wrote: > I could not get the mouse to work at all, however - no doubt an SDL > problem. And the SDL window is *huge* - was it always that way? What'= s > the correct window size it really wants? Here's a patch to get the mouse working in SDL. The window size wasn't that easy to fix, since there are FB size/code dependencies. I'm looking at this next (unless someone else is doing that, in which case I'll go directly to networking). -- Bj=F6rn --------------010702030202080807090605 Content-Type: text/x-patch; name="sdl.c.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="sdl.c.patch" *** sdl.c.~1~ 2005-11-28 21:26:00.000000000 +0100 --- sdl.c 2005-12-05 16:57:44.000000000 +0100 *************** *** 87,108 **** static void sdl_send_mouse_event(void) { ! int x, y, dx, dy, /*dz, */state, buttons; state = SDL_GetRelativeMouseState(&dx, &dy); - buttons = 0; if (state & SDL_BUTTON(SDL_BUTTON_LEFT)) ! buttons |= MOUSE_EVENT_LBUTTON; if (state & SDL_BUTTON(SDL_BUTTON_MIDDLE)) ! buttons |= MOUSE_EVENT_MBUTTON; if (state & SDL_BUTTON(SDL_BUTTON_RIGHT)) ! buttons |= MOUSE_EVENT_RBUTTON; ! ! state = SDL_GetMouseState(&x, &y); // iob_sdl_mouse_event(x, y, dx, dy, buttons); } --- 87,122 ---- static void sdl_send_mouse_event(void) { ! int dx, dy, state; ! extern unsigned char sib_mouse_motion_reg; ! extern unsigned int sib_mouse_x_pos; ! extern unsigned int sib_mouse_y_pos; state = SDL_GetRelativeMouseState(&dx, &dy); if (state & SDL_BUTTON(SDL_BUTTON_LEFT)) ! sib_mouse_motion_reg |= 1<<6; ! else ! sib_mouse_motion_reg &= ~(1<<6); if (state & SDL_BUTTON(SDL_BUTTON_MIDDLE)) ! sib_mouse_motion_reg |= 1<<5; ! else ! sib_mouse_motion_reg &= ~(1<<5); if (state & SDL_BUTTON(SDL_BUTTON_RIGHT)) ! sib_mouse_motion_reg |= 1<<4; ! else ! sib_mouse_motion_reg &= ~(1<<4); ! ! sib_mouse_x_pos += dx; ! sib_mouse_y_pos += dy; + #if 0 + logmsgf("Mouse event: x %d (%d), y %d (%d), buttons %04x\n", + sib_mouse_x_pos, dx, sib_mouse_y_pos, dy, sib_mouse_motion_reg); + #endif + // iob_sdl_mouse_event(x, y, dx, dy, buttons); } --------------010702030202080807090605-- From dseagrav@lunar-tokyo.net Mon Dec 5 18:00:03 2005 From: dseagrav@lunar-tokyo.net (Daniel Seagraves) Date: Mon, 5 Dec 2005 12:00:03 -0600 (CST) Subject: [LMH] Lisp timing issue solved In-Reply-To: <43947E7F.30004@Victor.se> References: <200512051739.jB5HdOWi029315@mwave.heeltoe.com> <43947E7F.30004@Victor.se> Message-ID: On Mon, 5 Dec 2005, [ISO-8859-1] Bj=F6rn Victor wrote: > Brad Parker wrote: > > I could not get the mouse to work at all, however - no doubt an SDL > > problem. And the SDL window is *huge* - was it always that way? What'= s > > the correct window size it really wants? > > Here's a patch to get the mouse working in SDL. The window size wasn't > that easy to fix, since there are FB size/code dependencies. I'm > looking at this next (unless someone else is doing that, in which case > I'll go directly to networking). If you have the latest code, redefining FB_WIDTH and FB_HEIGHT at compile time changes the SIB's idea of the host FB size. I've tested this with the console driver. It defaults to 1280x1024 if undefined. From brad@heeltoe.com Mon Dec 5 22:10:22 2005 From: brad@heeltoe.com (Brad Parker) Date: Mon, 05 Dec 2005 17:10:22 -0500 Subject: [LMH] File bands In-Reply-To: Your message of "Mon, 05 Dec 2005 11:09:25 CST." Message-ID: <200512052210.jB5MAMQq017152@mwave.heeltoe.com> Daniel Seagraves wrote: >Does anyone know how to change file bands or read the contents of the >other one? The sys-intro manual says to read the I/O reference, but we >don't have it. I don't know how but I think it's in the partition info. My "epart.c" program shows one of the properites (0x4) set for FIL1 but not FIL2. I'll try setting it for FIL2 and seeing what happens. (FS:LMFS-LIST-DIRECTORIES) will list the directories. There are 6-7 but don't contain much of interest. (fs:lmfs-list-files "dirname") will list the files in that dir. The local file system does work, as I can create an save files. I'd like to get NFS going so then I can pull files in and compile them... btw: I see this pretty regularly "CPU: MD CLOBBER PROTECTION STOP 7" -brad From dseagrav@lunar-tokyo.net Mon Dec 5 22:23:11 2005 From: dseagrav@lunar-tokyo.net (Daniel Seagraves) Date: Mon, 5 Dec 2005 16:23:11 -0600 (CST) Subject: [LMH] File bands In-Reply-To: <200512052210.jB5MAMQq017152@mwave.heeltoe.com> References: <200512052210.jB5MAMQq017152@mwave.heeltoe.com> Message-ID: On Mon, 5 Dec 2005, Brad Parker wrote: > btw: I see this pretty regularly "CPU: MD CLOBBER PROTECTION STOP 7" Can you reproduce this on command? It means an unmapped memory write was started while a read was outstanding. The stop is for safety. It means lisp is expecting a stall-for-cycle-completion somewhere and it isn't happening. There's probably a read immediately before the stop that isn't happening. Next time you get that, dump WCS and send me the WCS dump file and the Micro-PC the stop happened at and I'll sort it out. (Or just tell me how you got it) From brad@heeltoe.com Mon Dec 5 22:29:34 2005 From: brad@heeltoe.com (Brad Parker) Date: Mon, 05 Dec 2005 17:29:34 -0500 Subject: [LMH] File bands In-Reply-To: Your message of "Mon, 05 Dec 2005 17:10:22 EST." <200512052210.jB5MAMQq017152@mwave.heeltoe.com> Message-ID: <200512052229.jB5MTYq8017983@mwave.heeltoe.com> Brad Parker wrote: > >I'll try setting it for FIL2 and seeing what happens. There doesn't appear to be a valid file system on FIL2... -brad From dseagrav@lunar-tokyo.net Mon Dec 5 22:42:29 2005 From: dseagrav@lunar-tokyo.net (Daniel Seagraves) Date: Mon, 5 Dec 2005 16:42:29 -0600 (CST) Subject: [LMH] File bands In-Reply-To: <200512052229.jB5MTYq8017983@mwave.heeltoe.com> References: <200512052229.jB5MTYq8017983@mwave.heeltoe.com> Message-ID: On Mon, 5 Dec 2005, Brad Parker wrote: > There doesn't appear to be a valid file system on FIL2... Ah, OK. I was curious what it was. From dseagrav@lunar-tokyo.net Tue Dec 6 22:18:07 2005 From: dseagrav@lunar-tokyo.net (Daniel Seagraves) Date: Tue, 6 Dec 2005 16:18:07 -0600 (CST) Subject: [LMH] D'oh! (Keyboard bug solved) In-Reply-To: <200512052229.jB5MTYq8017983@mwave.heeltoe.com> References: <200512052229.jB5MTYq8017983@mwave.heeltoe.com> Message-ID: Apparenly I didn't know the difference between key CLOSE and key OPEN. I had inverted the make/break bit. >_< I hate making stupid mistakes! Fix in next commit after I do some cleaning up. From brad@heeltoe.com Tue Dec 6 22:59:13 2005 From: brad@heeltoe.com (Brad Parker) Date: Tue, 06 Dec 2005 17:59:13 -0500 Subject: [LMH] D'oh! (Keyboard bug solved) In-Reply-To: Your message of "Tue, 06 Dec 2005 16:18:07 CST." Message-ID: <200512062259.jB6MxDKp029599@mwave.heeltoe.com> Daniel Seagraves wrote: >Apparenly I didn't know the difference between key CLOSE and key OPEN. >I had inverted the make/break bit. > >>_< > >I hate making stupid mistakes! Fix in next commit after I do some cleaning >up. The SDL version didn't seem to have that problem; it seems to take keyboard input fine - Bjorn's fixes clean up some of the mappings also. Someone gave me a native X interface for usim (thanks!); I could easily graft that onto meroko if anyone would like. It's very snappy but the keyboard mapping is not quite right and needs a little help - unshifted keys work fine but shifted keys are broken. I'm starting to think we should make one "native i/o" library which usim & meroko share which does native, sdl & x and handles all of the keyboard mapping in a unified way. It would be easy to do. There are some other projects (like mwm) which might want it also. -brad From rgantar@gmail.com Mon Dec 12 16:49:35 2005 From: rgantar@gmail.com (gantar) Date: Mon, 12 Dec 2005 17:49:35 +0100 Subject: [LMH] When was the CADR project discontinued? Message-ID: ------=_Part_8482_15327487.1134406175913 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline The last documents on bitsavers date from 1984. This is probably when Richard M Stallman threw in the towel and nobody was left to continue working on it, right? -- ^----X^ ( ' . ' ) ------=_Part_8482_15327487.1134406175913 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline The last documents on bitsavers date from 1984. This is probably when
Richard M Stallman threw in the towel and nobody was left to continue
working on it, right?

--
^----X^
( ' &nbs= p;.  ' )
------=_Part_8482_15327487.1134406175913-- From brad@heeltoe.com Wed Dec 14 19:04:41 2005 From: brad@heeltoe.com (Brad Parker) Date: Wed, 14 Dec 2005 14:04:41 -0500 Subject: [LMH] carry bug in usim Message-ID: <200512141904.jBEJ4fiX028014@mwave.heeltoe.com> Hi, I noticed the other day that when I typed "(+ 1.0 1.1)" into usim I got the wrong result. Other floating ops seemed to be ok, but fadd seemed to be broken. I fooled around with some tracing and discovered that the carry code in the ALU was broken. I suspect this is also causing the scheduler to crash. I'm not sure, but I think that was due to a time overflow problem, also affected by the add carry. I have a simple fix. I want to rework that 64 bit code at some point to use (faster) 32 bit operations, but for now it seems to be right and 1.0 + 1.1 = 2.1, which is good :-) just thought I'd mention it. -brad From spanishmillion@netscape.net Thu Dec 15 17:52:30 2005 From: spanishmillion@netscape.net (SPANISH SWEEPSTAKE) Date: Thu, 15 Dec 2005 18:52:30 +0100 Subject: [LMH] SPANISH E-MAIL RESULT SPANISH SWEEPSTAKE LOTTERY INTERNATIONAL PROMOTION/PRIZE AWARD DEPT. CALLE GRANVIA 32N 1C MADRID SPAIN REF: RSSL/61-ILGI0509/45 BATCH:RSSL/15/096/WRCS RE: WINNING FINAL NOTIFICATION 15/12/05 Dear Winner, WINNING NOTIFICATION We happily announce to you the draw of the Royal spanish Sweepstake Lottery International programs held on the 1st of November 2005 in Madrid Spain.Your e-mail address attached to ticket number: 212005600545 188 with Serial number 4888/02 drew the lucky numbers: 41-6-76-13-45-8, which subsequently won you the lottery in the 2nd category.You have therefore been approved to claim a total sum of 1,000,000.00 Euro(One million Euro) in cash credited to file KPC/9080333308/03.This is from a total cash prize of Ten Million Euro(10 million Euro), shared amongst the first Tenth (10th) lucky winners in this category.Please note that your lucky winning number falls within our Madrid booklet representative office in Spain as indicated in your play coupon.In view of this, your 1,000,000.00 Euro(One million Euro) would be released to you by our security firm in Madrid,Spain.Our agent will immediately commence the process to facilitate the release of your funds as soon as you contact him.All participants were selected randomly from World Wide Web site through computer draw system and extracted from over 100,000 companies. This promotion takes place annually. For security reasons, you are advised to keep your winning information confidential till your claims is processed and your money remitted to you in whatever manner you deem fit to claim your prize. This is part of our precautionary measure to avoid double claiming and unwarranted abuse of this program by some unscrupulous elements. Please be warned. To file for your claim, please contact our fiduciary agent: Mr Jim Lopez Santa Maria Security&Consultant Madrid Spain. . Email:santamariaser@netscape.net or santamariasevice@netscape.net For due processing and remittance of your prize money to a designated account of your choice. Remember,You are to contact our agents by email and within a week of receiving this notice.After this date, all funds will be returned to the MINISTERIO DE ECONOMIA Y HACIENDA as unclaimed. To avoid unnecessary delays and complications,please quote your reference/batch numbers in any correspondences with us or our designated agent.Congratulations once more from all members and staffs of this program. Also be informed that 10% of your lottery winning belongs to the security company because they are the company assigned to process your winnings to you. NOTE this 10% will be collected after you have received your winning prize because the money is insured in your name i.e email address already. Yours Sincerely, Wilfred Alberto Lottery Director.