Subject: re: Bob's amazing hard-drive plans... In article on <24 Oct 94 14:13> [EMAIL PROTECTED] wrote:
Hi Simon! Cs> I had a long chat to Bob at the show, Ooops, I missed it. I was supposed to be building a comms disc for Brian to take to show off the sam-comms, oh well there's always next year..... Cs> and here's what the hard drive Cs> is going to be like: His might! but I'll be [EMAIL PROTECTED] if anything I connect to my sam will be! Cs> He has a "team" (doubtful) working on Cs> changing the basic ROM -- he's Cs> going to rip out the network code and Cs> replace it with an options Cs> screen (ala multiROM???? Methinks so) Cs> to boot from disc (f7), hard- Cs> drive (f8) or network (f9) (how, if Cs> he's ripping out the network Cs> code?) (f8) network boot! What a dumb idea! An RS232 boot maybe but even that's uneeded! Cs> The Hard Drive will occupy ports Cs> 234-235 (ARGH! they're LPT2!!!) and Cs> apparently the "design group" are Sounds like he's working on an XT card adaptor! Another well dumb idea! Cs> having problems getting enough Cs> drives smaller than 40Mb to work with Cs> -- ie I think we're talking Cs> stupid file system that can't handle Cs> more than 40Mb HD's here folks... Again that points to the XT standard... Cs> Oh, and he wants to change how the dos Cs> works -- apparently putting Cs> the device in the filename is a no-no, Cs> so he's putting down these Cs> standards: The whole idea of LOAD'ng a file should be dropped, I'd prefer OPEN, GET, PUT, READ & WRITE. LOAD and SAVE should be supervisor functions to get the main executable into ram, from then on files should be treated as files not just somthing to be loaded into ram in its entirety.... But that would mean loss of compatabiltiy with the speccy style of programming<g> Cs> CAT instead of DIR must be used Cs> (although you can do it the other Cs> way, in programs it will be changed back) Cs> <<"Because you CAT a directory, you Cs> don't DIR a directory">> That's purely a cosmetic change... duno what it's supposed to achieve... peecee's use DIR and like it or not that hasn't stopped their onslaught! Maybe he's trying to get back to his speccy roots again, a techno-mid-life crisis;-) Cs> LOAD d1"filename" instead of LOAD "D1:filename" Cs> (although, again, you should be able Cs> to use the other, but it's not Cs> "preferred") Cs> <<"the device shouldn't be part of the Cs> filename as it causes all Cs> sorts of problems">> Cs> LOAD p<number> instead of LOAD <number> Cs> He wants it all to be very G+DOS Cs> compatible. I say hit him over the Cs> head with a cleaver -- the dimwit Cs> wants to keep it at Spectrum levels. Most people seem to view the sam as just a speccy with more ram and better graphics:-( I think the crappy machine-code DOS interface is one reason why most applictions are totally ram-bound, and because most applications are ram-bound, disk based utils like ARC,LHA,ZIP arn't usable... and native users are stuck with system compression of files that only work in a ram-bound enviroment... sigh its all catch22 Cs> Needless to say in the next issue of Cs> SAM Prime, we'll be printing the Cs> PD hard-drive design, now that we've Cs> seen the crap he's coming up Cs> with. Would that be a derivative of mine;-) The MAIN benifit of using hardware 8<->16 bit bus conversion and the IDE bus is that the HOST speed is totally unimportant the only requirment is that the data buffer is read before the next command is issued! Other than that you can do it fast using 2 INIR instructions or byte at a time and correct the byte ordering if talking to IDE CD-ROM drives;-) Bobs insistance of using unbuffered XT technology means he'll be hard pushed to reliably feed & read the data registers in time! plus he's doing away with IDE ECC in favor of old CRC techniques plus IDE will re-map dodgy sectors on-the-fly plus some have transparent read-ahead buffering... the list just goes on and on! Cs> What I'd like to know is how the hell Cs> are you supposed to be able to Cs> change drives. If you want a program Cs> to use either drive easily on Cs> the SAM currently, you can do: Cs> LOAD drive$+filename$ Cs> How the **** do you do it if you're Cs> forced to use LOAD d1"filename" Cs> ????????????????? This was done on the +D's I can't produce the solution as all my good 3.5" drives are in service on the sam and pc... but it can be done:-) Oh and to load a string-named file the syntax is:- LOAD d1;a$ the ; has to be used as a seperator or it screws up! LOAD d$;a$ Might be the way.... or was it a numeric variable for the drive... I duno... If all else fails a direct poke would do it;-) Of course if the +D syntax is duplicated entirely then using:- LOAD D*;a$ and you just poke the DVAR that sets the default drive to the one that you want... and return it back to the old default afterwards, now isn't that good... NOT! I'm begining to think that a full-blown banked unix would be MOST useful! Sam can use the line-interupt as a maskable timer thats disabled whilst in the kernal but ticks away whilst a task is running and auto swaps tasks according to internal tables. Thanks Si for the reply address:-) CYS. Johnathan. ___ Olms 1.60 [Evaluation] -- |Fidonet: Johnathan Taylor 2:2501/307 |Internet: [EMAIL PROTECTED] | | Standard disclaimer: The views of this user are strictly his own.
