| ??? 09/07/04 18:48 Read: times |
#77057 - RE: Efficiency Responding to: ???'s previous message |
Yes, but I should imagine the OS (can we really call it an OS?) would be fully aware of what hardware it was connected to and read/write to it as efficiently as possible. It seems that what we had gotten to was an OS API on the central 8052 that application programs would access. The actual OS would then do the work of farming out the operation to the appropriate external hardware (or doing it itself if its one of the functions handled by the central 8052). The central 8052 would communicate with external hardware via some yet-to-be-determined communications protocol. Games programmers would naturally ignore the OS entry points altogether and write directly to the hardware. If you add an extra layer of abstraction (an API to cater for different display devices, for example) you'll be giving the 8051 a lot more work to do. I don't see this device being used outside of our little 8052 community so I don't think we're going to see some huge "game programmer" industry springing up. I also don't think the programmer would gain much by ignoring the OS and doing it himself since the OS would, in the case of external hardware, mostly exist just to save the programmer the hassle of performing the off-chip communication himself. The OS API also allows for the possibility of subsequently modifying the hardware or the communication protocol without having to go back and modify every program written for the device. Surely a large part of the fun is to see how fast you can get it to go? It would be a bit disappointing if it wound up slower than a 20 year old home micro... That's a valid point. But considering the old machines were 1.79 MHz and we could conceivably use a, what, 33-50 MIPS 8052 we'd have to do some insane code bloat to slow things down that much. Again, it's a balancing act between performance and flexibility. If the thing is too slow then we've obviously moved too far towards flexibility. But I really don't think the things that we've talked about are so CPU-intensive so as to slow things down. It's really just providing a standarizing API layer. And, yes, I think we need to call it an OS. It needs to contain functionality to address some external storage, be it IDE hard drive or SD cards, and load/unload programs on demand. Anything less would just be a glorified SBC. I don't really understand how the flexibility to use different display devices will make it seem more like a computer. All it's got to do is plug into the telly and display 320*200 in 16 colours and it'll seem exactly like a computer. It's not that the flexibility of using different devices will make it feel more like a computer. It's just a design consideration that can be easily incorporated at this point. The alternative is designing the entire system around a specific video solution or a specific storage solution, etc.--which will work but it'd be a mess if we ever wanted to try to push things further in the future. Might as well consider other possibilities now when it is easy to design for. Regards, Craig Steiner |
