Hi, we just uploaded a new article to
http://people.squeakfoundation.org/article/60.html. SqueakNOS: A simple guide to writing HardwareDevices SqueakNOS currently has support for PC Keyboards, PS/2 Mouse, Serial ports and the Real Time functionality of the CMOS chip on PCs. In this article I will use the latter as an example to explain how new HardwareDevice could be implemented. I will also include a list of the most wanted devices, and some open questions I'd like to discuss with interested people. The current status of SqueakNOS calls for collaboration on many aspects, and supporting more hardware is one of the most important. we hope you enjoy it. gera |
Hello Gerardo,
Friday, June 9, 2006, 11:44:49 PM, you wrote: GR> SqueakNOS: A simple guide to writing HardwareDevices Nice! How about a BinaryStorageDevice to mount a raw HDD partition, so something like GemStone can run there? No file system for you (alas, a large identity hash is needed for this to work properly). I liked the alarm example, and it reminded me of dealing with int70h, which is triggered by reprogramming the RTC. As opposed to the alarm, which is sent until you tell it to stop, int70h will be sent only once unless you tell it to keep going. You can select many different frequencies, and this does not affect the RTC's time keeping. Maybe it will be useful for something. Good stuff! -- Best regards, Andres mailto:[hidden email] |
In reply to this post by Gerardo Richarte
I have not had time to play with SqueakNOS, but this is really a
great project and I'm enjoying reading about it. Thanks. Dave On Sat, Jun 10, 2006 at 01:44:49AM -0300, Gerardo Richarte wrote: > Hi, we just uploaded a new article to > http://people.squeakfoundation.org/article/60.html. > > > SqueakNOS: A simple guide to writing HardwareDevices > > SqueakNOS currently has support for PC Keyboards, PS/2 Mouse, Serial > ports and the Real Time functionality of the CMOS chip on PCs. In this > article I will use the latter as an example to explain how new > HardwareDevice could be implemented. > > I will also include a list of the most wanted devices, and some open > questions I'd like to discuss with interested people. The current status > of SqueakNOS calls for collaboration on many aspects, and supporting > more hardware is one of the most important. > > we hope you enjoy it. > gera > |
I agree with Dave and I'm in the same situation, not time right now,
but I'm VERY interested in this project. Hope find some free time, at least to start reading and trying. Cheers. gsa. 2006/6/10, David T. Lewis <[hidden email]>: > I have not had time to play with SqueakNOS, but this is really a > great project and I'm enjoying reading about it. Thanks. > > Dave |
In reply to this post by Gerardo Richarte
hola Andres! donde estas?
> GR> SqueakNOS: A simple guide to writing HardwareDevices > > Nice! How about a BinaryStorageDevice to mount a raw HDD partition, > so something like GemStone can run there? No file system for you > (alas, a large identity hash is needed for this to work properly) > Yeah! that'll be the first step (after having low level support for HD I/O), however, I think we will anyway have something like files on the hard drive, at least if only to organize different memory segments or something. However, I never ever looked at the low level details of an Object Storage system, so I may be 100% wrong (for example, if they work like a big memory image with garbage collection and everything). > I liked the alarm example, and it reminded me of dealing with int70h, > which is triggered by reprogramming the RTC. heh! nice, good memories from the old days coming bacl! :-) int 70h in DOS is the handler for IRQ 8 (IRQs for the 2nd PIC are mapped from 70h to 78h in DOS). In the example in the article we are using IRQ 8, which is no other than int 70h disguised as an object :-) > As opposed to the alarm, which is sent until you tell it to stop, int70h will be sent only once > unless you tell it to keep going. Weird... in our case IRQ 8 continued to be triggered until we read register C from the CMOS/RTC. (which is no other than just an I/O port reading). May be you were doing this just to check if the IRQ was in fact coming from the RTC? > You can select many different frequencies, and this does not affect the RTC's time keeping. That's nice! I was not sure if this would affect the time or not. I think I'll try to see how many IRQs per second we can handle from Squeak without loosing any, and without killing the responsiveness. I'll report back as soon as I do it. Nice to hear from you! and thanks for the ideas! take care gera |
Hello Gerardo,
Sunday, June 11, 2006, 12:12:16 AM, you wrote: GR> hola Andres! donde estas? En mi casa, por supuesto! :) GR> if they work like a big memory image with garbage collection and GR> everything. Yes, modulo details. GR> Weird... in our case IRQ 8 continued to be triggered until we read GR> register C from the CMOS/RTC. (which is no other than just an I/O GR> port reading). May be you were doing this just to check if the IRQ GR> was in fact coming from the RTC? See attached, that's where I got the info from. I did include int70h functionality is some of my programs and it worked great --- with the exception that aborting the program caused immediate crashes as the int70h handler was not restored properly. -- Best regards, Andres mailto:[hidden email] in70h.rar (10K) Download Attachment |
In reply to this post by Gerardo Richarte
Hi Richie. I'm glad to know SqueakNOS is back. I have always been a fan of it! >> You can select many different frequencies, and this does not affect the RTC's time keeping. >> > That's nice! I was not sure if this would affect the time or not. I > think I'll try to see how many IRQs per second we can handle from Squeak > without loosing any, and without killing the responsiveness. I'll report > back as soon as I do it. > Some time ago (486 OS/2 3.0), doing low latency audio experiments in Squeak, I was able to get about 5000 with no problems with a custom device driver and a C plugin. I could get smooth real time dsp with a latency of about 0.2mS. I could even control the plugin with a Morphic GUI. The limit was the time the CPU needed to respond to the interrupt (it was documented in the Intel manuals). I guess it must be faster these days. Cheers, Juan Vuletich |
Free forum by Nabble | Edit this page |