The Spectrum is a computer for GIRLS !!!
in [Commodore]
|
From: Adam on 23 Nov 2006 00:51 Hihi Vanessa Ezekowitz wrote: > > They briefly resurrected the sinclair compatible market a couple of years > > ago. With the e-m(a)iler. total flop of course, the charges to send e-mail > > with the thing were too high. (It ran spectrum games) > Interesting. They tried to resurrect the C64 a few times as well, all of > which were flops until the DTV/Hummer came along. Those seem to have done > pretty well. Have you seen how hackable those things are? I've got three of them (well, two of them after I lifted a SM resistor off the board trying to attach a PS/2 connector on my second one, but heh), you can reprogram the flash with whatever software you want (I wrote a small tool for building filesystems for that device although it still doesn't compress the files), connect IEC devices and a PS/2 keyboard and only 8 quid from Argos, you cant' go wrong! > To me, an OS is just a kernel and a handful of basic utilities to handle > stuff like copying files, moving things around, installing more software, > and maybe compiling programs. A full operating environment in my mind > means a full blown GUI like KDE or similar. Really on the 8 bits machines what you got in ROM was the OS (with the noteable exception of machines like the Sharp MZ80A, MZ700 and Tatung Einstein and similar where you had to boot your OS from Tape/Disk) > Speed loaders for C64 tape drives generally break 10 kbps. Not in this universe, heh. That would mean any game loaded in a tad under 50 seconds once the speedloader started, it was generally 3 or 4 times that if you were lucky... Even the super high speed you'd-better-save-in-the-middle-of-the-tape routine in the action replay couldn't load/save a file in 50 seconds, heh, a couple of minutes as I recall > No, I'm using bytes where I mean bytes. Test it yourself. Get a good > fastloader routine. Load 50KB from a stock 1541 drive (use an emulator > like VICE). You'll find it's nowhere near as slow as you're claiming. Warp 25, 202 block program, 8 or 9 seconds I did like my action replay :> -- Adam
From: Adam on 23 Nov 2006 00:56 Hihi [Lack of SAVE "foo" CODE x,y on the C64] > Sure you can, using the ROM routine I mentioned. > > Four POKES and a SYS command and the block of memory you specify is saved to > disk. This can be called from within a BASIC program or at the 'command > line'. How is that from Basic? You're clearly leaping into the ROM, lol Also, that procedure isn't documented in the C64 manual -.o, at least not the one that comes with it, I should probably eye the reference manual but tbh I don't remember seeing it there either although it's been a while. > The code is prefixed with an execution address as the first two bytes of > data written to disk. Auto-executable programs usually mess with the Are you sure that isn't the load address? I'm fairly sure it is... > CHRGET routine (if I remember the name), which resides down in Zero Page, > or they might overwrite the last bit of the Processor Stack instead. When > a program finishes loading, the CHRGET routine is called, which by the time > the load is finished, is pointing to a new piece of machine code. In the > case of stack manipulation, the load ends up placing it's own start address > into the stack where the KERNEL had originally put a "return to command > line" address. In both cases, as soon as the LOAD command returns, a new > address gets picked up and the code is executed before the command line is > ever reached. Still not really as easy as SAVE "bar" LINE 10 though :p
From: zeem on 23 Nov 2006 02:35 Mike Wynne wrote: > "zeem" wrote... >> Except maybe the Electron in screen modes 0, 1 or 2, but that's because >> it's slower than the Beeb in the same modes. > > That's because the Acorn engineers in an amazing cost cutting move decided > to use a single 64k x 4bit RAM chip for the 32k x 8bit memory, meaning that > every read/write required two memory accesses... wonderful idea! I couldn't remember the exact reason, although I know that it was for cost-cutting. Isn't there also another reason that's something to do with the ULA in the graphics modes I mentioned, making it especially slow in those modes because the ULA is hogging the RAM? Apparently Acorn devised, and Slogger implemented, a speedup hack, whereby the lower 8K of RAM was removed from the range accessible by the ULA, which nearly doubled the speed of the machine under certain circumstances. -- Alex Taylor
From: spike1 on 23 Nov 2006 05:32 follow-ups restored. Now why would I allow that followup-to setting? Post something I can't see a reply to? That would be madness. Vanessa Ezekowitz <vanDEesLEsaTEezTHekISowitz(a)gmail.com> did eloquently scribble: > I had intended only to compare the computers, not the disk drives. > The C64 was introduced in 1982 with an MSRP (Manufacturer's Suggested Retail > Price) of $595. At the time of release, one US dollar was worth about 0.59 > pounds, making the C64's MSRP about 351 pounds. > In the USA, few retailers actually use an item's MSRP and instead set their > own prices. Here, many more retailers use the RRP and only reduce it for things like sales and special offers. Yes, shopping around can cut the cost... But I don't think there were many special offers on those new fangled computery things in the very early days, they were too much of an unknown. Within about a year and a half of the start of the home computer boom in 1981, places you wouldn've never expected to stock computers were selling them. Boots the chemist, WH Smiths the news-agent, etc. Now, you'd have expected them to maybe sell in TV, Hi-Fi and electrical shops, but CHEMISTS? >> I doubt a spectrum with a fuller box for sound and microdrives hit much >> more than the 250 quid mark. Maybe it hit the 400 quid mark for a spectrum >> disk interface like discovery... But that's compared to over 700 quid for >> the commodore. > My initial estimate came out to about 265 pounds for Spectrum 48K with a > decent tape deck, Microdrive interface (but without the drive) The interface 1 came with a drive. You could chain up to 8 together, but you got one in the package with the interface to start you off. , joystick > adapter, and one or two other minor things, or roughly US $449 using 1982 > figures. >> Ah, as standard... nope, don't think the fuller box came anywhere close to >> 150 quid. > If that Fuller box is around 50 pounds (sounds about right to me for 1980's > era sound hardware), then you're at 315 pounds (about US $533) for a > Spectrum 48K setup that almost matches up to a C64 (on a feature-by-feature > basis that is). Feature by feature, the spectrum would by then only lack hardware sprites (woopydoo). But it would GAIN on the microdrive. >> Well, commodore overcharged atrociously. >> I take it the [Commodore 64] did not cost 650 quid for the basic model >> with datacorder over there? > Nope, see above. The datasette was an odd phenomenon, with a rather high > MSRP of $75 (considering it had been out for a number of years prior to the > C64's release). In 1982 figures, thats 44 pounds. So, if you remove the need for the interface 1 (ok, so you lose the serial port as well as the microdrive interface it you dump that) and stick with tape (which most people did), you didn't have that �44 quid outlay. Everyone had a tape recorder back then, any old tape recorder would do. And if you DID need a new one, you could pick one up for 15 quid from any electrical retailer. >> I take it the 1541 didn't cost over 800 dollars >> over there? (that's basic exchange rates using the approximate 2 dollars >> to the pound of the time) >> >> Who could afford 1500 dollars for a commodore with disk drive when you >> could get something fairly comparable for less than 600? > The MSRP for the 1541 was $399 or about 235 pounds. Hmmm, well I've not been able to find the retail prices over here in the uk yet. But we're not called rip-off britain. Quite often we have a direct dollar-pound conversion on some inports. I wouldn't be at all surprised if the 1541 cost �399 here. > MSRP of a C64, 1541, and datasette was $969 in total (about 571 pounds). > Not cheap, but a lot less than you were suggesting before. Are you doing currency conversion? Or are you actually using the UK RRPs? > In June 1983, the C64's retail price dropped to $250, the 1541 had dropped > to some $299, and the datasette doesn't appear to have changed appreciably. And of course, price drops in the uk, lagged behind. If they happened at all. > So in 1983, you could expect to spend about $624 (412 pounds) assuming the > datasette price didn't change. I suspect currency conversion. >>> Personally, I would have been irritated had the C64 not been designed >>> with all of its features already present. >> >> Like a specialised datacorder that couldn't even manage 300bps without >> help? The spectrum used a standard cassette recorder. And saved at approx >> 1200bps as standard. > No, more like the other things like the User Port and joystick ports. The > datasette port was of little use to me actually. And like I said, the > datasette reads/writes at 45 to 60 bytes per second (thus 450 to 600 bps). Every spec sheet on the c64 I've found on the web so far lists the datasette as being 300bps as standard. >>> The disk drive was faster than the tape drive without any software or >>> hardware help, as mentioned below. >> >> It wasn't faster than the spectrum tape routine as standard. >> It was SLOOOOOOOOOOOOOOOOOOOOOOOW. > I was referring specifically to 1541 versus datasette. > A stock 1541 is most certainly faster than your tape drive as well as ours, > but I'll grant you the speed of your Microdrive being superior. No, sorry... But our tape drive was quicker than your disk in many situations. Given a standing start with the tape in the right place. > An easy way to check is to turn the volume all the way up so that you can > hear the digital background noise, and then load a large program. Each > burst of noise you hear represents 254 bytes, and you'll hear a little less > than 2 such bursts per second. I again suspect a bit/byte mixup. And listening? That's no way to measure bit speed in transfers. The correct method is to save and load a file of a known size and get the machine to (if possible) time itself. (Or time it with a stop watch if, like the spectrum, the loading routines disabled interrupts) >> No, it doesn't. >> If it had a completely different hardware profile to the vic, why didn't >> they include ANYTHING in the rom for handling that hardware? EVERYTHING >> required pokes or machine code. Really helpful. > ENTIRELY different hardware profile. > For data I/O, the VIC-20 used 6522 chips. The C64 used 6526's. > For video, the VIC-20 had it's VIC-I chip, the C64 used the VIC-II. > For sound, the VIC-20 used the sound generators in the VIC-I. The C64 used > a SID chip. > The VIC-20 had a variable system memory map, the C64's was fixed. > The VIC-20 came with 5KB of RAM. 3.5K of RAM. I remember that much. (Unless it was just 3.5K that was available to the poor programmer. Mind you, it was an early one and the comparable machines all had small RAM too... 1K on a zx81, for example) The C64 has 64K. > As I said, the hardware profile is entirely different. The VIC-20 is > nothing like the C64 under the hood - all similarity stops at the keyboard > mechanism and case itself. I didn't argue against it being entirely different. In fact, I said the hardware was completely different. All I argued about was the fact the ROM was essensially the same between the two in spite of these differences. Every time sinclair released a new machine, he'd update the BASIC to take advantage of the new features. In ZX80 to ZX81 these changes were minimal hardware wise, but the basic was extended to include floating point, a "SLOW MODE" to allow a constant display, PLOT/UNPLOT and a few other things. When the spectrum came out the BASIC was massively updated, with the addition of sound, colour, graphics, better dimensional and string variable handling, DEFFN, READ/DATA/RESTORE, stream handling with OPEN #/CLOSE # PRINT #, etc. Fixed ROM hooks for future additions like the interface one. (cat, erase, format, etc) When the spectrum 128 came out the machine's ROM underwent another step up. Now the basic could be entered using typed keypresses in 128 mode or the traditional single keyword entry in 48k mode. The spectrum 128 only added 2 new commands, play and spectrum (which switched to 48k mode for BASIC), but some commands were modified to allow access to RAM disks, etc... But the 128 mode's menu system added some new features too. Such as a built in calculator, renumber, tape loader, better line editor, etc. Meanwhile, throughout all this, the commodore 64 had exactly the same version of BASIC as the commodore PET from 5 years before! >>> I can see why Commodore kept the BASIC 2.0 ROM though: with >>> thin profit margins as is common with computers, >> >> Thin profit margins? >> Oh, my sides. > Actually I take this back, the profit margin on the C64 was fairly thick > (the machine cost $135 to make, with a wholesale price of $360). Thought as much. :) >> The operating environment IS the OS. Operating system, operating >> environment, same thing. The kernel is not the OS, it's just the core of >> it. (the heart or brain if you want to anthropomorphise it) > To me, an OS is just a kernel and a handful of basic utilities to handle > stuff like copying files, moving things around, installing more software, > and maybe compiling programs. A full operating environment in my mind > means a full blown GUI like KDE or similar. But then how do you seperate things out when comparing it with windows? You can't strip the GUI from XP and still have a working operating system. OK, in linux, you can dump the GUI altogether, or switch between any one of a few dozen alternatives (I use blackbox, not KDE for example) >>> The tape drive loads at about 45 to 60 bytes per second without >>> fast-load, >> >> LOL.. 2400 bps? >> Using the standard tape load routines on a commode datacorder? > 45 bytes per second is 450 bits per second, not 2400. I think you got > something confused here. You're multiplying by 10? 60 bytes per second X 8 (8 bits in a byte) = 2400 bits per second. Upper bounds for comparison because you said it could get up to that speed. The standard tape routine on the commodore 64 using a standard datacorder has been listed on numerous websites as 300 bits per second. >> The spectrum ROM routine was 1200 approx. Of course, speed loaders on the >> spectrum bumped that up to over 2400. > Speed loaders for C64 tape drives generally break 10 kbps. Sorry... but considering the confusion with the 300 bits per second thing, I think I'll reserve judgement on that one. >>> which is slow, but manages about 1000 bytes per second with a fastloader, >> >> Rubbish. I'm sorry but I refuse to believe the datacorder could manage to >> cram 8kbps onto audio tape and work reliably, if at all. > How they did it, I have no idea, but the fact is, they did it. I don't > understand tape routines too well, but I do understand that they're not FSK > or FM, they're some kind of quadrature encoding - '1' bits use a different > pulse duty cycle than '0' bits. >> >>> which is commonly included within the program's code. Programs that use >>> fastloaders (which was most of them) generally loaded in under 5 minutes. >> >> Errr... >> your maths is terrible. >> According to you, a program would load in under 5 minutes... >> The absolute maximum you could expect to load into a commodore 64 would be >> 65535 bytes. > Actually, in practice it's about 50KB in a single chunk due to the layout of > the memory map. You generally copy some data around after the first 50KB > is loaded, and then load the other 13KB in one or more additional chunks. > That leaves 1K unused, which is generally reserved for system variables and > the like, but that can be overwritten as well if you're not using the ROM > code within your program. >> That means judging by your loading time and assuming the absolute max was >> being loaded, the absolute fastest you could manage with your datacorder >> was 65535/(5*60) >> �218.45 >> 218.45*8 >> �1747.6 >> >> So, let's just assume it's not the full memory image that's loading and >> round it down to 1500bps. >> That's not exactly impressive when the spectrum managed 1200 without any >> enhanced loading routines. Considering you had a custom tape player, >> I'd've expected better. > As I said, tape loaders have achieved about 1000 bytes per second before. a > 50KB program file would load in about 52 seconds after the initial few > seconds it takes to get the fastloader started. > I should point something out - when I say "bps" I mean explicitly "bits per > second", which is the standard notation used over here. I'll explicitly > state bytes per second when I mean bytes. It's standard here too. bps = bits per second, but you're stating bytes per second a lot too. KBps is kilo bytes per second for example and (and I quote) ------------- >>> The tape drive loads at about 45 to 60 bytes per second without >>> fast-load, ------------- >> If it did, no-one would've complained about the speed of it, being able to >> load the full 64k in 11 seconds would've been fine. > Since you started this calculation with "datacorder", your math is totally > wrong. 1000 bytes per second divided into 51200 bytes equals about 51.2 > seconds. > Now from the 1541 side of things, the default speed of about 400 bytes per > second means that you can load a full 50KB of program code in one go in > about 128 seconds, without a fast-loader. Don't believe me? Time it > yourself. I may be off, but I am definitely not off by more than a few > dozen bytes per second. OK.... I admit I screwed up on the maths. It was a bit late. :) I plead tiredness. -- ______________________________________________________________________________ | spike1(a)freenet.co.uk | "Are you pondering what I'm pondering Pinky?" | |Andrew Halliwell BSc(hons)| | | in | "I think so brain, but this time, you control | | Computer Science | the Encounter suit, and I'll do the voice..." | ------------------------------------------------------------------------------
From: Matthew Westcott on 23 Nov 2006 05:43
spike1(a)freenet.co.uk wrote: > 60 bytes per second X 8 (8 bits in a byte) = 2400 bits per second. *cough* |