[Coco] Windows vs. Linux (was 512K upgrade)

[L. Curtis Boyle]

Yeah... we had a lot of plans, that we just ran out of time (due to work, mostly), and then others took over and went in different directions. I still wish we had implemented the "full extension" to the hack Alan did between Grfdrv and SCF (the 32 byte write buffer). I was planning on adding two mode bits to module header (currently only has 'single tasking' or something like that - one for buffered read, one for buffered write. I was then going to have those bits have to be present both in the driver and the descriptor; if both were set, it would use the buffered versions. If one or both were not set, it would use the regular "1 byte at a time" sequence. This way, one could force certain devices to not use buffered I/O, just by setting the bit in the device descriptor, and mix/match drivers the same way (say, allow buffered write only to windows, buffered read/write to serial ports, buffered write only to printers, etc.
Wouldn't have sped up quite as much as Alan's grfdrv/scf patch (since normal SCF, to write a single character, had to send that character
through CC3IO, SCF, Windint (which then mapped the 2nd system map MMU blocks in with IRQ's off, to bring in grfdrv), then grfdrv, which then wrote ONE character to the screen. A _lot_ of overhead. Enabling buffering on other SCF drivers/devices would not save the extra MMU mapping/grfdrv setup... but everything else it would. 
Alan had the write buffer set to 32 bytes, from what I remember.... could have even expanded that (64?), as well as add the read equivalent.

L. Curtis Boyle
curtisboyle at sasktel.net



On Mar 12, 2014, at 10:20 PM, Bill Nobel <b_nobel at hotmail.com> wrote:

>  Yes I do agree Curtis,  We were hoping the screen mapping system could catch on.  Obviously not, but aside from that from OS9 a user still could create the same effect through their own user created calls added to a boot file (i.e. os9p3, krn3) I have been still playing with the mapping in Nitros9 for various things.  Shanghai was the perfect example of that.
> 
> On Mar 12, 2014, at 9:42 PM, L. Curtis Boyle <curtisboyle at sasktel.net> wrote:
> 
>> Ironically, Bill and I did put some GetStat calls in NitrOS-9 (around 1.15? 1.16? Can't remember) that allowed one to get the MMU block numbers for any screens you were using, specifically for doing games. You can "legally" map in a screen created by VDGINT already, of course, which is what games like Koronis Rift use, but we wanted the best of both worlds (you could use "normal" display commands for graphics primitives like lines, bars, circles, text fonts, etc., plus windowing commands, the Multi-Vue GUI, etc.... but you could also map the screen in for direct access). Since you could allocate multiple screens, you could even do screen flipping games this way. The first version of Shanghai that Bill Nobel ported actually used this call, to make the direct screen writes "legal". Unfortunately, I believe this was later removed, and the GetStat as well. There were a few things removed (including transparency for hardware text fonts), which was disappointing... we wanted to e
> xp
>> and the OS, not just keep speeding it up.
>> I don't know if these have been reinstated in the latest versions... hopefully, somebody still active in NitrOS-9 can let me know.
>> 
>> In other words, Nick - we were settings things up so that you wouldn't mind NitrOS-9 so much... :-p
>> 
>> L. Curtis Boyle
>> curtisboyle at sasktel.net
>> 
>> 
>> 
>> On Mar 12, 2014, at 9:28 PM, Gene Heskett <gheskett at wdtv.com> wrote:
>> 
>>> On Wednesday 12 March 2014 23:27:30 Mark McDougall did opine:
>>> 
>>>> On 13/03/2014 1:39 PM, Bill Pierce wrote:
>>>>> Nick, I was going to stay out of this one (even though it started
>>>>> from my post :-) until you said OS9 is slow....
>>>> 
>>>> Can someone please pass the popcorn?
>>>> 
>>>> Regards,
>>> 
>>> Why, you think this is going to be a long show? :)
>>> 
>>> Cheers, Gene
>>> -- 
>>> "There are four boxes to be used in defense of liberty:
>>> soap, ballot, jury, and ammo. Please use in that order."
>>> -Ed Howdershelt (Author)
>>> Genes Web page <http://geneslinuxbox.net:6309/gene>
>>> 
>>> 
>>> --
>>> Coco mailing list
>>> Coco at maltedmedia.com
>>> http://five.pairlist.net/mailman/listinfo/coco
>>> 
>> 
>> 
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>> 
> 
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>