Re: Junk mail
On 12 April 2012 10:55, Wayne Weedon wrote: > On 12/04/2012 10:23, Geoff Winkless wrote: >> >> On 12 April 2012 10:08, Wayne Weedon wrote: >> [snip valid points] >> >> Please, can we just drop this? >> > Not while he's deliberately and probably maliciously targeting members of > this list I wont. I didn't ask you to stop doing whatever you might plan on doing to him, I asked (politely, I might add) if we can please stop posting to the list about it. Whatever... your attitude has tipped the balance. The noise:signal ratio has got too high for me, and I guess I haven't contributed anything useful to the scene for a decade or so, so I won't be missed. When it gets to the point that people are this aggressive I'm just happier walking away. The sense of community and humour just isn't the same as it was; I suppose people grow up, get lives, jobs etc. Good luck with your fight against the evil spamtator, I guess just hitting "delete" is too hard for some people. Geoff
Re: Junk mail
On 12 April 2012 10:08, Wayne Weedon wrote: [snip valid points] Please, can we just drop this? I've had perhaps three emails (either directly or indirectly) from Roger in the last three weeks. And about 50 from other people going on about it. I know, this is another one. How ironic. ObSam: who decided that you shouldn't be able to move the cursor while a pipe piece was being placed in Sam Pipemania? Ruined the game :( Geoff
Re: Single pixel hardware scroll?
On 2 February 2012 11:02, Simon Owen wrote: > > On 2 Feb 2012, at 10:24, Geoff Winkless wrote: >> If you're thinking of playing with stuff like that in SimCoupé, how >> about adding in a screen start address OUT mod? I'd love to see what >> could have been done with just a small change to the ASIC design :) > > I was drawn by the possibility of there being something new and > unimplemented, though it's sounding increasingly unlikely. > > Still, I think your suggestion should be relatively easy to try, just for > fun! Just a single byte offset for the start address? How should wrapping > be handled? I'm in the middle of a sound revamp at the moment, but I'll put > it on the list to take a quick look after that. I was thinking a full two-byte offset with a rolling window. So normally ASIC looks at the VMPR for the RAM page, then (I imagine) keeps a 15-bit offset from 0 and reads byte-by-byte, incrementing offset as it goes (obviously doing weird stuff for mode 1, but I'm simplifying) If you could just change that 15-bit offset to start at XhXl using LD B,Xh LD A,Xl LD C,MyPortNumber OUT (c),A hardware scrolling, the cheap way. I think the BBC did exactly this. > Would that be possible with a real SAM peripheral? Can the value on the bus > be changed to redirect the display read? Or is it possible to modify the > value read instead? Perhaps something that watched for display reads and > cached the values, so it could supply a remapped value to offset the display? Uhh. I doubt it. The ASIC handles the value being read, so unless you can a) tell the difference between a normal address request and an ASIC request and b) either override that address or at the very least override the result that came back. I don't even think the ASIC memory requests appear on the bus, do they? Colin would know :) Geoff
Re: Single pixel hardware scroll?
On 1 February 2012 20:42, Simon Owen wrote: > On 01/02/2012 20:07, Thomas Harte wrote: >> I notice that whatever effect it thinks it is relying on doesn't work >> in Sim Coupe. > > It's certainly nothing that's implemented at the moment, but if it's > shown to be a real effect (like border pixels), it should go in. Though > it does feel like it could be specific to CRTs, and more likely those > that suffer from distortion due to intensity differences? I know the TV I first used would exhibit something similar. I wouldn't have thought you could ever rely on it though. Certainly the 8833 I ended up with wouldn't do it. > I remember there being some sample interlaced SAM pictures, which may > have relied on the effect to give the necessary vertical shift to help > with colour blending. I thought that was just about the fact that the TV would display alternate lines each 50Hz - so you could switch screens between two and effectively double your Y resolution, the problem being that you could never tell which would be the "top" and which would be the "bottom". If you're thinking of playing with stuff like that in SimCoupé, how about adding in a screen start address OUT mod? I'd love to see what could have been done with just a small change to the ASIC design :) Geoff
Re: Accessing Sam formatted disks through a USB floppy drive
On 27 July 2011 11:52, Dicky Moore wrote: > Geoff, Howard, Leszek, Simon, Nev, & Thomas, thanks so much for your help. > You're welcome, glad to hear you got your data back. Most of my Sam disks are unreadable; whether my original Sam was close to the edge of spec or whether the disks have just degraded over time I'm unsure. And congrats on the new arrival! Sell the Sam and invest in some heavy-duty earplugs :) Geoff
Re: Accessing Sam formatted disks through a USB floppy drive
Yes and no. Mostly no. http://webstore.kryoflux.com/catalog/product_info.php?products_id=28 is your best hope, I expect. Most standard USB floppy drives will only read standard disk formats, which means you won't be able to access the 10th sector on a Sam disk. No idea if the software works with Sam formats though. You're almost certainly better off dusting off an old DOS PC with an old-fashioned disk drive on it. Geoff On 22 July 2011 15:38, Dicky Moore wrote: > Hey all > > ** ** > > Has anyone had any luck in copying Sam-formatted floppy disks to .dsk or > .mgt images using a USB floppy drive? > > ** ** > > Samdisk doesn’t support USB floppy drives and I’m not sure of any other > software that can do this. > > ** ** > > I’m trying to recover all the E-tracker music I created back in the day. * > *** > > ** ** > > I’m trying to find an app that will make an image of the floppy disk, which > then I maybe could mount that as a virtual floppy drive and samdisk could > then work. No luck so far. Anyone have any ideas? > > ** ** > > Cheers > > ** ** > > Dicky > > ** ** > > -- > > Dicky Moore | Bearcraft > > 07702 100 180 > > http://dickymoore.co.uk | http://bearcraftmusic.com > > ** ** >
Re: egg chips and...
Shouldn't it be egg, beans and ... ?
Re: who wants some then ?
On 7 June 2011 10:15, David Sanders wrote: > If, like me, you get annoyed by endless rambling emails then please > just filter them. Replies to these messages are the only time I hear > about them at all, and it's always people complaining about them. > Or you could unsubscribe from the list, then you wouldn't have to read *any *of the endless rambling... I got the feeling that endless rambling was all we were left with. :) The raw enthusiasm does shine through despite the terrible spelling and construction and the complete lack of understanding or self-awareness. In a way I find it kind of endearing, in the way that other people's 6-year-olds are endearing as long as I don't have to look after them for more than half an hour at a time. And now I'm replying to your message about how annoying replies to messages about this are. Sorry. :) Geoff
Re: Contention and JR instruction timing.
On 26 April 2011 16:58, Chris Pile wrote: > I'm not sure having only a basic ability to shift the screen around would > have been much use without > additional hardware support. Such as sprites for example. Having to > render lots of software sprites > over nothing more than a shiftable 24k lump of RAM would get very messy > code wise. Especially > with the need for double-buffering to avoid glitching/flicker, Etc. > I don't understand this. You're saying that, because doing it with the help of a movable background would still be hard, we should be grateful that they didn't lumber us with the challenge to try to write it? Not to mention the poor old Z80 would still have a shedload of work to do > shunting the required data > around. Any scrolling game running at less than 50-fps with only > half-a-dozen or so on-screen entities > really wouldn't be worth the effort! Really? From memory most scrolling shoot-em-ups have a limited number of moving baddies at any one time. And most of the baddies move with the scroll, because the scroll is meant to represent the hero flying through the scenery... so the only thing you have to worry about is the Hero. > Fast shoot-em-ups are awful at anything less than TV frame-rates. > Ever played Wings of Death on the ST? One of the best shoot-em-ups I ever played, and the background moves slowly. I guess that's because the ST didn't have scroll hardware either, so they had to do chunks at a time. Difference being, the ST had the power to do the scroll (probably at about 5fps, from memory) and the baddies too. I doubt if the Sam can do that. Maybe it could - I guess if you move the whole screen once every 10 frames, that leaves you about half your processing power. Even slow Z80-based systems such as the Master System managed to do > full-colour, full-screen 50-fps > scrolling with full-colour sprites (albeit in limited numbers) over the > top. But then it did have a tile-based > system for the background which, although (for the most part) it is more > limiting than a true bitmap, it did > mean the Z80 had very little work to do to maintain a nice scrolling > backdrop. > > Besides, there's something *pure* about having a chunk of RAM and a CPU - > and not much else! > Oh sure, if you don't cripple your CPU. G
Re: Contention and JR instruction timing.
On 26 April 2011 15:55, Thomas Harte wrote: > And we're told that a selectable screen start address was considered but > not > possible in the current design > I'll be honest: until someone actually gives a proper reason why it couldn't be done I won't really believe that that's true. Maybe no-one thought it would be helpful. Maybe they did it but the ASIC didn't work properly. Maybe Bruce and Alan didn't like shoot-em-ups :-). I dunno. I do think it's a shame that no-one brought this up before they fabricated 30,000 ASICs or whatever it was. I remember one of the early Crash interviews with UK Gold (I think) where their guy was saying "they may have a problem moving the screen around". So it's not like no-one mentioned it before launch. G
Re: Contention and JR instruction timing.
On 26 April 2011 15:11, Tommo H wrote: > > On 26 Apr 2011, at 14:38, Geoff Winkless wrote: > > On 26 April 2011 14:23, Tommo H < > tomh.retros...@gmail.com> wrote: >> >> The 25fps is based on a hypothetical chip having the same access as the >> CPU does currently. >> > > But would still take up the majority of the bus time, meaning you couldn't > do anything _else_. > > > And at present, if you want to scroll the screen you can't do anything else > and you also can't really scroll the screen. I forget the exact numbers, but > you get about 79,000 memory access cycles a frame, don't you? So if a > hypothetical device which uses every access cycle, that's enough bandwidth > to read and write every byte on the display more than three times in a > single frame. > Umm... Well you can't read and write the same byte in the same cycle; but you're right, if the 79000 frames figure is correct that would be usable. However I'm not sure it is: system clock is 6MHz, so 6M T-states per second, that's 120,000 every frame (6M/50). That's about 30,000 memory cycles in screen-off. If you were going to invest in significant graphics hardware you'd be better off with scalable hardware sprites that aren't in system memory at all and having a 4-colour screen and using full 128-colour sprites for the interesting stuff. Admittedly they don't help you with 3d but at least you'd have half the memory to move around and half the contention to worry about. G
Re: Contention and JR instruction timing.
On 26 April 2011 14:23, Tommo H wrote: > > The 25fps is based on a hypothetical chip having the same access as the CPU > does currently. > But would still take up the majority of the bus time, meaning you couldn't do anything _else_. > I also disagree about the significant amount of electronics on the grounds > that Zilog's native DMA part cost less than $10 even in 1989 > $10 in a unit costing £200 retail is a significant cost. > Filled vectors are going to be not a huge amount quicker unless you make > the hardware a lot smarter - you'd spend most of your time setting up the > external registers to fill objects one line at a time. > > Based on profiling my filled vector code (not the stuff I've released, > better stuff), something like 80% of the total cost is the filling, and > something like 50% of the cost of the filling is CPU logic rather than > memory bandwidth. So the difference would promote a game of Mercenary > graphical complexity from unplayable to playable. > Erm, so you're saying that 40% of cost would be LDIRs replaced by 4 OUT instructions (say) and a wait while the DMA does its job (at say 50% of the original t-states of the LDIR itself)? I still don't buy that it would be any faster. You'd have to be blitting lines of more than about 20 pixels just to break even. (figures based on thumb-in-the-air estimates, so I'm probably quite a lot out, but you get the idea) G
Re: Contention and JR instruction timing.
On 26 April 2011 13:15, Thomas Harte wrote: > Apart from a desire for part uncontended memory (ala the Spectrum) and > a hardware scroll, a simplified blitter would have been advantageous > (eg, give it start address, end address, length, tell it to go and > then it replaces the z80 on the bus until the copy is complete; even > with the CPU having to do a lot of lifting around the outside and run > some other logic that'd give you a 25fps scroll if that's what you > wanted it for, or filled vectors if you prefer). > You end up having to contend with the video during the move so you're still talking about significant slowdown. You might get 25fps scroll but that would take most of your bus time, leaving you not much time to do anything else. Quite apart from the significant amount of hardware you'd have to add of course. Filled vectors are going to be not a huge amount quicker unless you make the hardware a lot smarter - you'd spend most of your time setting up the external registers to fill objects one line at a time. Failing that, I really don't think video adjust registers could have > cost that much. So you've a horizontal register and a vertical > register, each capable of taking values in the range 0 to 7 and will > offset the pixel output by that amount on the screen. They're timing > delays on the video output, essentially, but they buy you up to 8 > frames of scrolling with very limited redraw costs, and that gives you > enough time to prepare the next major offset on a secondary screen. If > memory serves, you get a similar thing for free in the 6845 that > appears in the BBC, Amstrad and VGA adaptors. > > What's the advantage over the writable screen-address idea? As far as I can see that involves more hardware and is way more complex to code for. It's only really useful in mode 4 if you need pixel-by-pixel horizontal scrolling. I guess it's useful on the Beeb (and indeed in Sam Mode 2) because there are 4-colour (and 2-colour) modes so byte-by-byte would be 8 pixels at a time. But Mode 2 is just such a horrible hack I pretend it doesn't exist :) G
Re: Contention and JR instruction timing.
On 26 April 2011 10:55, Chris Pile wrote: > Mmmm, not sure I would have like hardware scrolling to be honest. It would > probably > have meant a glut of scrolling marioesque platform games. Which - for me - > is a whole > lot less desirable than infinite ball demos! > Yes, scrolling platformers become possible, as do scrolling shoot-em-ups (doing it in Mode 2 doesn't count), but it also means you can open up to innovative stuff like Thrust and Exile that would never have been possible on a 2MHz processor. You also get much more responsive text editors, basic editors etc. > Some sort of blitter to chuck large blocks of data around at high speed > would have been > a *very* nice addition. That 24k screen really is too much for the old Z80 > to cope with! > Eugh... _another_ thing to add to Simon's memory contention list? :) A blitter would have been costly both in terms of electronics and in terms of memory T-states. When I said "free" I meant it - a single OUT statement could set the memory start address and everything else would have stayed the same, with the extra port taking the ASIC equivalent of a couple of sets of gates. I guess the current screen address currently just gets reset to 0 every frame - but if you wanted to save the extra electronics required for a screen address register you could make it so the software had to reset it every frame interrupt. Actually that's silly, there wouldn't need to be any per-frame reset logic, just some logic so that when when bits 13 and 14 are both set they're both immediately cleared (0x6000 -> 0x) On 26 April 2011 10:54, Simon Owen wrote: > Just those two could have made a huge difference to what was possible. > *sniffs* I do vaguely remember Simon Goodwin explaining why SAM missed out > on hardware scrolling, but I can't remember the details. I think it was > something RAM access related, so perhaps the change to use dedicated VRAM > would have made it easier? As a hardware n00b I've no real idea! Anyone? > I don't see how changing the start point within a 24k rolling window would make any difference to the RAM timing - you still have to access the same data the same number of times and at the same rate. My hardware experience is pretty limited though, so I'm not going to start contradicting Mr Goodwin. G
Re: Contention and JR instruction timing.
On 26 April 2011 10:08, Chris Pile wrote: > Hi Si, > > Yep - clear as mud! :-) > > Seriously, many thanks for the explanation - even my hardware-limited brain > managed > to understand all that! I take my hat off to hardware designers, it's > certainly a black art! > > Mmm. I often used to wonder why VRAM wasn't used... I guess Sam just missed the price drop? Can't find any readily available data on prices of VRAM in 1988 although the suggestion is that by 1990 or so it was only a 20% premium over DRAM. There's a page which suggests that up to then it was about 100%, which explains it I suppose. Would it have been better to have 48kB of more expensive display memory, giving only the live display and a secondary (for double-buffering) but losing the ability to use any page in RAM as the screen? I guess that means no more infinite-ball demos ... but I'm sure we could live with that :-) For me the real mistake, though, was the lack of capability to set the display address counter for instant free hardware scrolling (and for not much electronics, unless I'm missing something) - even the BBC Micro had that in 1982. Apologies, I'm hijacking the thread again. Erm, Hula-hoops: beef or salt-n-vinegar? G
Re: SAM Revival 24?
On 9 March 2011 13:43, Wayne Weedon wrote: > On 09/03/2011 00:21, Steve wrote: >> >> Any news on SAM Revival 24. >> >> .. out soon... 7th October 2010 ? >> > Gawd there is some life in the mailing list still! I was about to delete it > because it was so dead. It does feel a little like the Black Knight. Come back here, you yellow **! I'll... bite yer legs off! It's just a flesh wound! Geoff
Re: Dizzy (was:Porting spectrum games...)
On 13 August 2010 13:56, Tennebø Frode wrote: > > In the version im reworking, itll end up needing about 32-64k > > for dictionaries as well as about 8k for probabilities if i > > use the full lzma system. Im altering it to be more Sam > > memory size suited hopefully without reducing compressiong size. > > I appreciate the challenge in making extreme compression work on SAM, but > you need to achieve some significant compression benifits to make up for > that extra space which could have been used for slightly-less-compressed > data. :-) > > Well not exactly, because the decompression takes place once a level, after which you can reuse the space. If you can squeeze it into 24k then that's just the screen RAM. Like you though I'm dubious that you'd achieve much better compression than a fairly basic RLE algorithm, especially on the kind of graphics you want as background in a game (lots of large blocks of black and quite a few horizontal lines, usually). Happy to be proved wrong, of course :) Geoff
Re: possibly a useful Z80 resource
On 19/06/2010 08:31, Ian Spencer wrote: Know what you mean about the nostalgia, I'm sure my loft doesn't have as many Sam bits in it as yours but still a fair amount of bits and pieces including a couple of Sams, it was still the most fun computer I have ever owned and so don't think I want to sell them any time soon, even though I tend to use the emulator these days but like you a couple of Speccys and +D's under the dust there too. Funny how many people have these in their loft and yet how r...@r3 L000K they are on ebay :) The Z80 sig still my favourite processor for assembler programming. Ever done any Acorn:ARM code? I was with you until I did. Geoff
Re: New SAM emulator for Windows
My view is that back in '95 or so, when the emulators first kicked off, not emulating currently-available hardware made sense; however I think that these days anyone who wants to use the real machine will continue to do so whether on not their favourite bit of hardware is emulated. I will not be going back to slow loading times, corrupted disks and endless 5-minute modify-assemble-run-crash-reboot cycles. Those (like me) who just want to have a quick play with stuff they used to enjoy will probably only ever use emulators - I don't really see that the two markets overlap. But hey, I have little enough time to play with my "real world" stuff, let alone the nostalgic kind. I'm probably not part of either group any more :( Geoff 2010/3/2 Adrian Brown > Obviously opened a can of worms there :D It was only my thoughts, while i > understand what people are saying about the SID chip being connected in lots > of ways, but if 10 people made the same bit of hardware then they would > probably interface it differently. I guess I just wouldnt like people like > Colin stop making hardware as it got emulated and then people didnt purchase > the actual hardware. Then myself for one much prefer to use the real > hardware so it wouldnt stop me anyway. > > Always interested to see other peoples views on these things :D > >
Fwd: Re: Micro Men
I finally watched the show last night; I'm fairly disappointed because it was neither one thing nor the other - it wasn't really very funny (Hauser seemed to get the best lines, while the Sinclair-based humour mainly seemed to be based around laughing at his borderline-autistic outlook on life) but it wasn't particularly accurate either. They put in a few well-known anecdotal bits but played around with the timeline horribly - the QL and the C5 were out at around the same time, IIRC, their collective failure ultimately working together to bring Sinclair Research to its knees. They also seemed to conveniently forget that the Newbury Newbrain was actually developed by what was Sinclair Radionics, which suggests Sinclair's involvement in computer development had started well before 1980; they also missed out large chunks of the Sinclair development story in favour of some padding (including a fairly bizarre scene at the Mensa conference), so we're left with this idea that Acorn were working hard at development while Sinclair just plugged stuff together that already worked (we know that's not the case). They also messed horribly with the Acorn story - the Electron was out well before the timeline would suggest it but they couldn't produce enough for demand, then production finally got sorted and the demand had gone; finally although the majority of the shares were bought by Olivetti they still continued as a separate entity (unlike Sinclair Research who were to all intents and purposes absorbed into Amstrad) - indeed the Master was more of a success than the Model B, IIRC, I guess that didn't quite fit the overnight-success:failure story they wanted to portray. For me though the biggest shame was that they mentioned the major success story as an afterthought, as if it had happened later; AIUI the ARM chip was in development well beyond the whiteboard stage by the time 1984 clicked around. The hollywood-romantic in me would like to believe that Curry and Sinclair finally made it up though. Anyone know if that's true? G
Re: Micro Men
On Wed, 14 Oct 2009 09:45:36 +0200, David Sanders wrote: > That's a bit strong. I think foreign investors were already put off by > our far higher rates of pay in relation to newer manufacturing > opportunities in the far east. To call the workers of the 70s and 80s > "workshy" is to simplify a very big social problem into a Daily > Mail-style "solution" (IE - it's all those horrible worker's fault). > > I can't believe you think all industrial action is "moron"ic, Aha! A straw man! I don't and never said I did. The actions of the unions _in the 70s and 80s_ was utterly unreasonable. The idea of a union is that a fair settlement can be reached by having a negotiator who can speak and act on behalf of a large number of people, and that if one member is victimised by his employer that union can act in solidarity and protect its member. I am 100% behind that. The problem is that the unions had decided that, even though the economic realities, and not the companies themselves, were dictating the required action, they were not prepared to accept it. That, to me, is moronic. The most obvious example is Scargill, who would not accept that cheap foreign coal was making many UK pits, with difficult and relatively expensive extraction, unviable. And I said that the foreign investors were scared of a workshy british workforce, which is definitely how they were perceived in the early 80s, that perception caused by the action of the unions and the constant reporting of it in the media. Now we're getting seriously off-topic... erm, favourite crisp flavour anyone? :) G
Re: Micro Men
nev young wrote: Stuart Brady wrote: It seems to me that Sir Clive would never have been hugely worried about maintaining a strong position within the market in the long term... of course, that's not to say that he wouldn't have appreciated having a 'cash cow' to fund his other project... Then he should have put a 68020 and a proper floppy disk in the QL :-) I was thinking more along the lines of the UK having a manufacturing base. If, instead of many small fragmented companies all setting up their own manufacturing plant, there had been larger companies who could have outsourced the build to UK manufactures then it is just possible that the UK would have become what Taiwan is now. Even Bruce and Alan had to set up their own plant to build Sam using venture capital. How would things have panned out if they could have just had the build done by an existing UK company, who was already tooled up to build computers. They wouldn't have needed as much capital and it might not have been clawed back quite so quickly. Even Amstrad might have built their machines here rather than in Japan. It seems to me that successive governments since Thatcher have deliberately tried to remove any manufacturing capability from the UK. My belief is the action in the 70s and early 80s by the unions sealed the death knell of British industry; foreign investors were terrified of getting involved with a workshy, bolshy and self-serving union-driven workforce and the government was tired of sitting in the middle policing the morons at their picket lines. Now of course we have the CWU, the largest union (of course, since all the manufacturing unions are effectively extinct) holding the whole country to ransom, but that's a different story. To get back to the subject, I don't think the Sinclair:Acorn thing was what caused the PC to win; the 16-bits carried on the line for the home computers but by the early 90s everyone knew the PC was going to be a juggernaut; certainly once Windows started selling with PCs that could run it well (ie decent speed 386s) the micro was dead. Geoff
Re: ATT : Roger Jowett
Roger Jowett wrote: tasword+2 with tascon+d from format was much more my cup of tea im amazed no one has bothered to convert it for sam is it incredibly difficult to convert a 128k porgram I'm confused. I'm 99.9% sure I have Tasword for the Sam, no? Geoff
Re: SAM's 20th Birthday
Colin Piggot wrote: Quite a few things lined up for SAM Revival and I'm toying with the idea of a complete colour issue for a special 20th birthday issue - if I can find somewhere to do affordable magazine printing I'd really like to do a one-off glossy mag for the birthday - as Sam has never had a 'proper' glossy mag during it's life...! I've used these guys for printing before and been happy enough. I'm not sure if they would fit the bill but they've always been very competitively priced - I think they get the printing done in Eastern Europe and ship it over here. http://www.printmeit.com/view_product_Y.php?product=11 Geoff
RE: SAM Revival issue 22 out now!
On Thu, 8 Jan 2009 15:54:47 -, "Steve Parry-Thomas" wrote: > I don't have all my software install on this machine yet, if I did I could > burn it for you, Edwin could as well. > May be others ?? Colin? Si? I also have a Willem programmer in a drawer in the unlikely event that no-one else has immediate access to one. I assume this http://uk.farnell.com/atmel/at28c256-15pu/eeprom-parallel-256k-28c256/dp/1095782 would do the job for the chip itself? I don't have an UV eraser lamp otherwise probably http://uk.farnell.com/stmicroelectronics/m27c256b-15f1/eprom-cmos-256k-27c256-dip28/dp/1125431 would do too? Geoff
RE: SAM Revival issue 22 out now!
On Thu, 08 Jan 2009 16:18:06 +, I wrote: > I don't have an UV eraser lamp otherwise probably > > http://uk.farnell.com/stmicroelectronics/m27c256b-15f1/eprom-cmos-256k-27c256-dip28/dp/1125431 For low-cost, would this work? http://uk.farnell.com/atmel/at27c256r-70pu/eprom-256k-4-5-5-5v-27c256/dp/1095781 Obviously the one-time nature of the programming would make it a bit hairy on the old stress levels :-) but it's nearly half the price even of the EPROM. I assume the fact that it's rated at 70ns wouldn't be a problem? Geoff
RE: New projects & Byte-Back 2009
On Wed, 8 Oct 2008 12:23:47 +0100, "Steve Parry-Thomas" <[EMAIL PROTECTED]> wrote: > Its not in the best part of Stoke, £5.00 would have been ok, a £10 or > more? You will not be getting very much for your £10. CeBit - taking place on the same dates, is that some sort of insane joke? - is only €33. Compare and contrast. > (I would have to hire a car to get to the venue, I dont have a car any > more, plus car parking, plus ticket, food and beer its looking like a bit > more than a tenner) I'm sure someone could sort out carshare or something, can't they? Who's going? > But they also want me to buy a ticket before I can show the machines. It's stupid that they expect exhibitors to pay: stallholders who are trying to sell something should be expected to contribute to the costs of the show but hobbyist exhibitors are surely adding to the attraction, aren't they? They expect you to charge per game of Manic Miner, perhaps... Like you, I'd expect £5 or so for something on this scale. It's probably unreasonable but past experience of these events tells me that what I personally get out of it isn't really worth much more than that (unless Simon Goodwin will come out for a curry again *lol*). Certainly if I turned up and they asked for more on the door I'd be very tempted to walk away and spend my money at the local Grosvenor instead. I'd be likely to get more enjoyment from it. I suppose I'm not really the target market though - I maintain only a vague interest in these things. G
Re: New projects & Byte-Back 2009
On Wed, 8 Oct 2008 09:54:31 +0100, "Thomas Harte" <[EMAIL PROTECTED]> wrote: > Stoke-on-Trent, on the 7th and 8th of March 2009. The website is here: > http://www.byte-back.info/ > > Tickets are currently £10, but the website implies they'll become more > expensive at some later date. Seriously? _more_ than a tenner? "Come and see a 25 year old Outrun cabinet (which you wouldn't even pay to play in the arcade any more) and watch as a middle-aged baldy tries to pretend he's Eric Clapton." A tenner would be the _upper_ end of what I'd expect to pay, unless the website isn't doing justice to the event. Geoff
Re: Speed issue's with POINT (x,y)
On Thu, 18 Sep 2008 15:37:51 +0100, Geoff Winkless <[EMAIL PROTECTED]> wrote: > "test-up" would therefore be [snip] D'oh; of course this is wrong (one line in mode 4 is 128 bytes, not 256) so you'd have to add 128 to IX (or HL) rather than increasing I (or H) but you get the idea. G
Re: Speed issue's with POINT (x,y)
On Thu, 18 Sep 2008 13:26:15 +0100, "Thomas Harte" <[EMAIL PROTECTED]> wrote: > Maybe something like the following to get the colour of the pixel at (x, > y): > > 10 LET A=IN 252 BAND 31 > 20 LET BASE=(A+1)*16384 > 30 LET ADDR = BASE + (x/2) + y*128 > 40 LET BYTE = PEEK(ADDR) > 50 IF x BAND 1 THEN LET COL = BYTE/16 ELSE LET COL = BYTE BAND 15 I can't believe that would be any quicker (in fact I'd be amazed if it's not slower) than POINT(). The way to improve the speed in a generic way is to write machine code that checks the edges of a bitmap you pass it and tests the appropriate points on the screen. The _fastest_ way is to write a specific set of checks based on the sprite and the direction of movement. Basically, let's say you figure out that if you're moving upwards you need to test pixels 2 to 6 on line 0 and pixels 1 and 7 on line 1. Your code for "test-up" would therefore be LD A, (IX+1) # pixels 2+3 OR A, (IX+2) # pixels 4+5 RET NZ OR A, (IX+3) # pixels 6+7 INC I:IX (or whatever your assembler uses for that non-instruction) OR A, (IX) # pixels 0+1 line 1 AND &0F # isolate rightmost pixels RET NZ OR A, (IX+3) # pixels 7+8 line 1 AND &f0 # isolate leftmost pixel RET IIRC if you call this with USR you get the value in A as the result (or is it BC? Can't remember), so you can just IF USR(upcode)<>0 THEN GOTO HIT There are ways of passing parameters to USR functions, I can't remember how though :( I'm also not sure if using IX is better than INCing H and L (probably not) The problem with POINT (or similar) is that it has to completely recalculate the positions in memory for every check. That's slowed down even further because each time it has to access the values from BASIC's variable stack which (since it's all floating-point and they're stored in a non-optimal way) is ridiculously slow (it's a shame Andy Wright didn't see fit to add integer variables like you get in BBC Basic, for example) Geoff
Re: Grabbing floppy images
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> X-Sender: [EMAIL PROTECTED] Received: from [192.168.3.100, 82.108.154.19] via 88-96-166-22.dsl.zen.co.uk [88.96.166.22] with HTTP/1.0 (POST); Mon, 16 Jun 2008 15:30:42 +0100 User-Agent: RoundCube Webmail Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit On Mon, 16 Jun 2008 15:10:18 +0100, "Thomas Harte" <[EMAIL PROTECTED]> wrote: > It's a shame that CP/M didn't offer standard > (albeit likely to be much-slower-than-native) graphics routines, or > maybe there'd be a whole bunch of graphics adventures and 'useful' > productivity software. Like GSX, you mean? Geoff [apologies if this arrives (tw|thr)ice - webmail playing up]
Re: Grabbing floppy images
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> X-Sender: [EMAIL PROTECTED] Received: from [192.168.3.100, 82.108.154.19] via 88-96-166-22.dsl.zen.co.uk [88.96.166.22] with HTTP/1.0 (POST); Mon, 16 Jun 2008 15:29:47 +0100 User-Agent: RoundCube Webmail Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit On Mon, 16 Jun 2008 15:10:18 +0100, "Thomas Harte" <[EMAIL PROTECTED]> wrote: > It's a shame that CP/M didn't offer standard > (albeit likely to be much-slower-than-native) graphics routines, or > maybe there'd be a whole bunch of graphics adventures and 'useful' > productivity software. Like GSX, you mean? Geoff
Re: Grabbing floppy images
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> X-Sender: [EMAIL PROTECTED] Received: from [192.168.3.100, 82.108.154.19] via 88-96-166-22.dsl.zen.co.uk [88.96.166.22] with HTTP/1.0 (POST); Mon, 16 Jun 2008 15:29:50 +0100 User-Agent: RoundCube Webmail Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit On Mon, 16 Jun 2008 15:10:18 +0100, "Thomas Harte" <[EMAIL PROTECTED]> wrote: > It's a shame that CP/M didn't offer standard > (albeit likely to be much-slower-than-native) graphics routines, or > maybe there'd be a whole bunch of graphics adventures and 'useful' > productivity software. Like GSX, you mean? Geoff
RE: Attempts at 3d on the Sam?
Talking about division through multiplication and a table lookup, On Tue, 3 Jun 2008 08:28:21 -0700, "Simon Cooke" <[EMAIL PROTECTED]> wrote: > Never implemented it, but the principle is sound. It's not tremendously > different to a reciprocal table. I never implemented it on z80 but I did do the same on ARM (where it gives you a massive win since there's a MUL instruction but no DIV). Without wanting to teach egg-sucking, it's fairly simple in concept: you just multiply the two numbers then shift the result down. So to divide an 8 bit number in L by 14, you need to multiply by (256/14)= 18(ish) then use the H register as your result... so that gives you (effectively) L * (256 / 14) / 256 The 256's cancel each other out, so you end up with L * (1 / 14) Obviously there's a loss of accuracy but it does mean you can get away with a table of 256 bytes for an 8 bit divide. My problem is you still end up having to do a multiply, which (on z80) is way too slow. I'd be tempted to use a 64kiB divide table and to hell with it. Geoff
Re: Short, short questions
On Wed, 21 May 2008 17:09:32 +0100, Andrew Collier <[EMAIL PROTECTED]> wrote: > Correct. Always non-interlaced (despite various examples on Fred of > flickery pictures which purported otherwise). While (on a TV with 576 visible lines) you won't be able to get a 192 line output device to output alternate lines on a TV display by switching between two screens (since the pixels will take up more than one scan line), you should be able to get a weird kind of subpixel colouring which (ISTR) was what they were trying to do in the 16-bit colour demo on the Crash tape, IIRC. Geoff
Re: Short, short questions
On Wed, 21 May 2008 15:29:28 +0100, "Colin Piggot" <[EMAIL PROTECTED]> wrote: > Andrew Collier wrote: >> If I used IM1 this would require that either, a) the screen goes in > sections A >> and B, and the interrupt routine is actuially visible in pixels - or b) > the >> moveable window goes in sections A and B, and I have to duplicate the >> interrupt routine in nearly every page of memory. > > That's the approach I was taking years ago for Chrome, I'd have a couple K > dedicated to the main core of the code and interrupt routines at the start > of many 32K chunks of code and sprite data, so AB pages could be shifted > around keeping the screen in CD - with the 8K above the screen holding > other data. You'd only need 3 bytes in each page to jump to 57344 (or 57400, maybe). So that's 96 bytes taken rather than 256, although they're spread out through memory which could cause problems... You're right, though, Andrew - your example hadn't occurred to me. I did say I was happy to be wrong :) Geoff
RE: Short, short questions
I have to admit I was wondering the same. IM2 was necessary on the speccy because 0x38 was in ROM and couldn't be paged out but I see no reason not to use IM1 on the Sam. I'm quite happy to be told otherwise, of course :) Geoff On Wed, 21 May 2008 13:50:14 +0100, "Adrian Brown" <[EMAIL PROTECTED]> wrote: > Ok, i haven't read all the posts on this, but why not stick the code in > LMPR and use IM1 - saves having the table of vectors. > > Adrian > ** UIP Sam Port 4100+ lines of z80 and climbing > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of David Brant > Sent: 21 May 2008 06:46 > To: sam-users@nvg.ntnu.no > Subject: Re: Short, short questions > > I thought the idea of mode2 was you could have different vectors for > different devices connected well this throws a spanner in the works. But > > then again is there any hardware for the SAM that uses them? I think it > must > have been an old spectrum book that said this about swapping high,low > bytes. > After a little test and using old brain this is wrong. > > Dave > > - Original Message - > From: "Edwin Blink" <[EMAIL PROTECTED]> > To: > Sent: Wednesday, May 21, 2008 5:34 AM > Subject: Re: Short, short questions > > >> All 8 bits are used for LSB of the vector. The part where bit 0 always > is >> zero is when one of the Z80's IO chips is connected (PIO,SIO,CTC etc) > is >> connected. >> >> Edwin >> >> - Original Message - >> From: "David Brant" <[EMAIL PROTECTED]> >> To: >> Sent: Wednesday, May 21, 2008 1:02 AM >> Subject: Re: Short, short questions >> >> >>> I've just been looking at my books. Although I can't find the bit > that >>> said about swapping to high,low but I'm sure that I did read it >>> somewhere. It does say that the device only gives the bits 1-7 and > bit 0 >>> is always 0 giving 128 possible addresses. >>> >>> Dave >>> >>> - Original Message - >>> From: "David Brant" <[EMAIL PROTECTED]> >>> To: >>> Sent: Tuesday, May 20, 2008 10:49 PM >>> Subject: Re: Short, short questions >>> >>> This was based on info from a book called z-80 Workshop manual by > E.A Parr. The I register gives the high part of the table and the > hardware gives the low part to the table then takes that word for the service > routine. So if you start from one byte before the table and use the > same address for all entries and over run it by one it will work. My demo > of a full scrolling football pitch used this system, which I believe > you saw many years a go. Dave - Original Message - From: "Andrew Collier" <[EMAIL PROTECTED]> To: Sent: Tuesday, May 20, 2008 9:50 PM Subject: Re: Short, short questions > Hi, > > I'm sceptical about this claim. I've never heard anybody say that > the > vector formed is big-endian - it's just you don't know the byte > offset > from which the interrupt vector will be fetched. (As Edwin says, it > is > usually 255 - which is odd so your 1-aligned table will usually > work - > but I don't know that Sam's hardware guarantees this). > > So the high byte comes from I, the low byte from the data bus; this > > forms a 16 bit address which will be incremented once (which is why > > the table needs 257 bytes, not 256). You could, at least in theory, > > read the vector address from even or odd overlapping entries, which > is > why the usual strategy is to pick a vector address whose low and > high > bytes are the same. > > The last IM2 interrupt routine I wrote looked something like this: > > ds ALIGN 256 > IM2TABLE: equ $ > IM2BYTE: equ im2table/256 > > IM2TARGETBYTE: equ IM2BYTE+1 > for 257, DB IM2TARGETBYTE > > IM2TARGET: equ 257*IM2TARGETBYTE > ds IM2TARGET-$ > > EX AF,AF' > ... > > Andrew > > > On 20 May 2008, at 21:16, David Brant wrote: > >> Mode 2 uses a table with 128 word address but as byte high,byte > low >> not the normal low, high bytes >> >> So if you set your org/dump address to &??FF (i.e. &??00-1) >> >> and then do >> >> DEFWmode2.i,mode2.i >> >> so you have 129 words. >> >> mode2.i: >> di >> pushaf >> ina,(status.int) >> . >> . >> ei >> ret >> >> >> >> - Original Message - From: "Andrew Collier" >> <[EMAIL PROTECTED] >> > >> To: >> Sent: Tuesday, May 20, 2008 3:22 PM >> Subject: Re: Short, short questions >> >> >> >> >>> The usual strategies are to use mode 1, or to use mode 2 with a > 257- >>> byte table all >>> containing the same byte. >>> >> >
RE: New Stuff
I wrote: > You missed off Status of Ice Heh. Freudian Typo; of course I meant Statues. Geoff __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: New Stuff
Dan Dooré wrote: >> But maybe World of SAM could keep a page of current projects? > > Something like this do? http://www.worldofsam.org/node/575 You missed off Status of Ice G __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: MC Interrupts
Geoff Winkless wrote: > Anyway, something like: [snip] Sorry, it's been a while and I was tired (!!), those local JP's should all (of course) be JR's! Geoff __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: MC Interrupts
Calvin Allett wrote: > so would it seem feasable to be able to alter the routine > with a flag, so that it jumps straight back every other frame > and only draws the other frames? Assuming you don't need to worry about redrawing them if they haven't moved you could simply add your own interrupt handler to check whether the positions are the same and don't call the sprite routine if they are. If your BASIC program _is_ changing the display then you will have to call them every frame anyway, since the masks will go horribly wrong otherwise (in fact, won't they anyway?) I'm confused why you'd want to fake hardware sprites with interrupts anyway, why not just write some MC to blat the sprite and call it from your BASIC routine? That gives much more fine-grained control. Anyway, something like: MyInt: PUSH HL PUSH BC Sprite1: LD BC, LD HL, (SpritePos1) SBC HL, BC JP Z, GoSprites Sprite2: LD BC, LD HL, (SpritePos2) SBC HL, BC JP NZ, GoSprites Sprite3: LD BC, LD HL, (SpritePos3) SBC HL, BC JP NZ, GoSprites Sprite4: LD BC, LD HL, (SpritePos4) SBC HL, BC JP NZ, GoSprites POP BC POP HL reti GoSprites: LD HL, (SpritePos1) LD (Sprite1+1), HL LD HL, (SpritePos2) LD (Sprite2+1), HL LD HL, (SpritePos3) LD (Sprite3+1), HL LD HL, (SpritePos4) LD (Sprite4+1), HL POP BC POP HL JP OldHandler It's not exactly optimal but it's fairly obvious what it does. Geoff __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Sound Chip
David Brant wrote: > I've been looking at the Coupe Technical Manual and noticed that the > Sound chip ports are write only. > So how did the demos show the sound volumes? Because the demo is writing the volumes out in the first place. Geoff __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Majordomo results
James R Curry wrote: >> > 96 subscribers >> >> Is it just me, or has the mailing list had around 90-100 members >> for pretty much ever? :) >> >> Gavin >> > > ...and 87 of them are Bob Brenchley. ;) _I_'m Spartacus! G __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Another year, another pyz80 revision
Simon Owen wrote: > Geoff Winkless wrote: >> and real-time code reassembly? :) > > To inject new code into a running SimCoupe, or something more? It Well ideally what I would want is proper integration with the debugger and the source editor, so I can - Visual Basic stylee - step through the source and modify any line I want without restarting. I was only kidding, hence the smiley. Geoff __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Another year, another pyz80 revision
Simon Owen wrote: > Andrew Collier wrote: >> So if you're doing any assembly language development on the Sam, > > why not check it out? > Output from other assemblers may need a some tweaking, particularly if > the labels lack a trailing colon. The assembler directives might be > slightly different too, but that's only a small part of the source. > > So, what are you waiting for? :-) Integration with SimCoupé to include clock-accurate debug stepping and real-time code reassembly? :) Geoff __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE:
Chris Pile wrote: > who Don't you mean "whom"? :) Geoff __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: SamForth
Colin Piggot wrote: > John Avis wrote: >> Does anyone have a copy of SamForth ? > > Just booted up SamForth from the Sam Suppliment... > > FORTH (C) J.A. AVIS 1991 > > So you're the author ? The sam-users list's first example of Viral Marketing, only 15 years too late :) G __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
pipemania (was RE: Golden ASIC's)
Chris White wrote: > Ps I fired up my sam tonight and till got a smile watching my mates > pipe mania booting n working , and then spent 3 hours playing sphere > one of the top classic shootems Ugh, Pipemania. I loved that game on the ST - my mate and I used to play it all the time, then the Sam version came along. I snapped it up and played it maybe twice; the gameplay was utterly broken. Geoff __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: Documentation (and E-Tracker)
Stuart Brady wrote: That's reminded me... I would very much like to know how to produce phasing sounds with E-Tracker. Could someone upload a module demonstrating this, or explain how to achieve the sound, please? Thanks, Never used etracker, but usually the way I'd produce a phasing sound in a tracker is to start two channels playing the same note and then pitch-slide down and back up (on two consecutive beats) one of the channels. It will then be marginally out-of-phase. The phase depends on how much you slide it, of course. Others may have other ways, that's how I do it though. Geoff
RE: Who`s missing?
david wrote: > MSN's probably the safest bet I think... chat rooms > seem to be a waste of time - people are never > in/awake/whatever... But the whole point of a list like this is that people don't have to be online in order for a conversation to take place. If people want to arrange between themselves to chat at a certain time about a certain topic that's up to them but moving the list wholesale to MSN is IMO a Bad Idea. Geoff __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Anyway to get WAV output from SAA32?
rob wrote: > there is a little proggy called Sound Capture by MagicSoft out there > on T'internet, you can MP3 it using that then convert to WAV. Its a > nice program, should have been called Ronseal.. If you'd rather have proper bit-accurate (I'm told) WAV then totalrecorder is supposed to be the dog's. I've not used it though and IIRC it's about $10 (what's that now, £5.50?) Geoff __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: 10th Anniversary!
Colin Piggot wrote: > Andy Chandler wrote: >> Congrats Colin, nice one ! >> Here's to another 10 ;-) > > Cheers! > >> Do you have any plans to do H.A.T.E.? >> That was always one of my favourite Gremlin titles. > > I don't have any plans to do H.A.T.E for the time being i'm afraid! > It's going to be hard enough to find the time to work on Thing On A > Spring and Harlequin in amongst a few other projects that i've got on > the go at the moment. Supercars!! Geoff __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
OT: Bring back the Wispa!
I know this is offtopic but in the best traditions of comp.sys.sinclair, where crisp/sweet discussions were almost on-topic... http://www.PetitionOnline.com/wispa91/ Come on, let's get the Wispa back! So much nicer than the nasty Nestlé Aero and Cadbury's replacement (Bubbly) isn't as nice :( Geoff __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: How to erase sectors?
[EMAIL PROTECTED] wrote: > [EMAIL PROTECTED] wrote: >> So I assume the best idea is to have a program which scans directory >> structure for unused sectors and fills them with zeros (including >> direc= tory entries of erased files). Does anybody know what program >> can do this? > > Look up SDU or IBU that I used to flog. > > Although not ideal they are written in basic and so will be easily > modified. > They scan the directory and calculate which sectors are "live" and > copy only those. So erased files wouldn't copy to a blank disk. Realistically it shouldn't be hard to write a program to go through the directory sectors on a disk, OR the "live" sectors of each (undeleted) directory entry and then write 0s to each sector which isn't live. You could even do it (slowly!) in BASIC - I forget the BASIC syntax for sector disk access - is it READ FROM and WRITE TO or something? If you're talking disk images, it would be really easy to write a program to modify the image to do it, given the Masterdos manual (that does contain the disk format info, doesn't it?). G __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: Fastest memory transfer (on Sam)
Yes, I'm still harping on. Sorry :-)
Edwin wrote:
> Like the Idea. So I looked a bit better at LDIR in ROM too.
>
> LDIR is made up of 5 M-cycles:
> 4,4,3,5,5 for standard LDIR = 21T
> 4,4,3+1,5,5+2 LDIR in RAM with RAM contemption = 24T
> 4+4,4+4,3+5,5,5+6 LDIR in RAM with Display contemption = 40Ts
> 4,4,3+1,5,5+2 LDIR in ROM with RAM contemption = 24Ts
See I disagree about this...
Won't it be
[4]
[4]
Loop around:
{3},{1 WAIT} 4 cycles
{5},[3 of 5] 8 cycles
[2 of 5],[2 of 4] 4 cycles
[2 of 4], {2 WAIT} 4 cycles
or 20 t-states per byte? (plus initial setup, of course)
> When looking at a LDI:
> 4,4,3+1,5+3 LDI in RAM with RAM contemption =20Ts
> 4+4,4+4,3+5,5+3 LDI in RAM with display contemption =32Ts
>
> From the above timings you can see that a block of LDIs is 4Ts or
> 16.6% per byte faster then a LDIR (anywhere) during RAM contemption.
Don't think so.
> But during display contemption a LDIR in ROM is as fast as a LDI in RAM.
This is true.
To clarify:
LDIR in ROM, RAM contention
[4]
[4]
Loop around:
{3},{1 WAIT}
{5},[3 of 5]
[2 of 5],[2 of 4]
[2 of 4], {2 WAIT}
LDIR in ROM, DISPLAY contention:
[4], [4]
loop around:
{3}, {5 WAIT}
{5}, [3 of 5]
[2 of 5], [4], [2 of 4]
[2 of 4], {6 WAIT}
ie 32 t-states
LDI in RAM, RAM contention:
{4}
{4}
{3}{1 WAIT}
{5}{3 WAIT}
Still 20 t-states. So RAM-contended RAM-based unrolled LDIs are as slow
(fast) as ROM-based LDIR.
LDI in RAM, DISPLAY contention:
{4}{4 WAIT}
{4}{4 WAIT}
{3}{5 WAIT}
{5}{3 WAIT}
32 t-states. So display-contended RAM-based unrolled LDIs are as slow (fast)
as ROM-based LDIR too.
Of course you still have additional CALL/RET times (32 RAM-contended or 64?
DISPLAY-contended) but that plays against the issue of the inflexibility of
unrolled LDIs.
Or am I (still!!) missing something?
Geoff
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__
RE: Fastest memory transfer (on Sam)
Please disregard last message: I'm being stupid.
I wrote:
> See I disagree about this...
>
> Won't it be
>
> [4]
> [4]
> Loop around:
> {3},{1 WAIT} 4 cycles
> {5},[3 of 5] 8 cycles
> [2 of 5],[2 of 4] 4 cycles
> [2 of 4], {2 WAIT} 4 cycles
Ignore me. I've missed a [4] out.
Geoff
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__
RE: Fastest memory transfer (on Sam)
Edwin Blink wrote:
> From: Geoff Winkless <[EMAIL PROTECTED]>
>
>> Without wishing to appear stupid (yeah, I know, too late, haha), I'm
>> still not clear why that's a memory access.
>
> It's not. The delay is added there for convenience. But in fact it
> will delay the next
> opcode fetch (unless it is in rom but read below).
>
>> Shouldn't that round up to 4,4,8,8,5 if in ROM with display
>> contention
>> and 4,4,4,8,5 with RAM contention?
>
> The delay shifts to the next (HL) cycle on next LDIR.
Whuh?
> the RAM can be accessed once every 8T during display(PAPER for Ales)
> contention and once every 4Ts during RAM contention
But there will be no RAM access for 8 t-states after the ,5 - the 4,4 will
take 8 t-states, so the RAM will be available again.
If what you're saying is that actually everything is broken down into chunks
of 8-t-states _regardless_ of whether there's a memory access, then that's a
bit more understandable...
_However_, what that actually means is:
If instructions in []s are ROM-based (or internal) and in {}s are RAM-based
(therefore must be 8-state aligned):
[4],[4] (one block) -- 8 cycles
{3} (one block) -- 8 cycles
{5} (one block) -- 8 cycles
[5] + [3 of 4] (one block) -- 8 cycles
[remaining 1 of 4] + [4] + {3} (one block) -- 8 cycles
{5} (one block) -- 8 cycles
[5] + [3 of 4] (one block) -- 8 cycles
[remaining 1 of 4] + [4] + {3} (one block) -- 8 cycles
This suggests that after the initial round, it will in fact only take 24
cycles per byte.
Actually, it's more like this:
[4],[4] (one block) -- 8 cycles
{3} (one block) -- 8 cycles
{5} + 3 of [5] (one block) -- 8 cycles
[2] of [5] + [4] + [2] of [4] (one block) -- 8 cycles
remaining [2] of [4] + {3} (one block) -- 8 cycles
but that's effectively the same.
If you go back to "each display-contended access takes exactly 8 cycles"
then you have
[4],[4]
{3} -- 8 cycles
{5} -- 8 cycles
[5]
or 29 cycles.
So which is it? Is it RAM availability is in 8-cycle blocks or each RAM
access takes exactly 8 cycles?
Or is it worse than that?
Please understand that I'm not trying to be awkward; I just don't comprehend
the logic.
Cheers!
Geoff
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__
RE: Fastest memory transfer (on Sam)
Edwin Blink wrote: >> Incidentally, what are the 5 cycles for an LDIR? > > It uses the same technique as used by relative jumps to add a value > of -2 to PC. Without wishing to appear stupid (yeah, I know, too late, haha), I'm still not clear why that's a memory access. I've found a more helpful list to the one I was using and it says the final 5 is internal operations, so in ROM it should just take 5 cycles, surely? http://www.z80.info/z80ins.txt According to that, LDIR is 4,4,3,5,5 for fetch, fetch, read, write, internal ops. Shouldn't that round up to 4,4,8,8,5 if in ROM with display contention and 4,4,4,8,5 with RAM contention? That would mean that > 4,4,3+5,5,5+6 LDIR in ROM with Display contemption = 32Ts ought to be 4,4,3+5,5+3,5 = 29Ts since the next instruction fetch will also be in ROM and therefore uncontended. Compared to 24+48/14 or 27.43 means the stack method is still faster, but you also need to bear in mind the setup cost of storing the stack pointer (or leaving it in a known state) and any registers you want to keep, plus the lack of flexibility and memory costs. I wonder at what point it becomes worthwhile. Of course using ROM routines means you have to have the ROM paged in and therefore drop back to the system interrupt routines and lose 16k of memory access. So either way it's not win-win. The ideal solution, of course, would be to build a custom ROM with a set of PUSH/POP's. But that defeats the object somewhat, since if we're resorting to hardware solutions then a blitter accelerator board (or a redesigned ASIC with such capability built-in) would be far the best option :) G __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Fastest memory transfer (on Sam)
Edwin Blink wrote: > From: Geoff Winkless <[EMAIL PROTECTED]> > >> Trying to think this through... > > Like the Idea. So I looked a bit better at LDIR in ROM too. > > LDIR is made up of 5 M-cycles: > 4,4,3,5,5 for standard LDIR = 21T > 4,4,3+1,5,5+2 LDIR in RAM with RAM contemption = 24T > 4+4,4+4,3+5,5,5+6 LDIR in RAM with Display contemption = 40Ts > 4,4,3+1,5,5+2 LDIR in ROM with RAM contemption = 24Ts > 4,4,3+5,5,5+6 LDIR in ROM with Display contemption = 32Ts Mmm. Makes sense. It's "contention", btw. Incidentally, what are the 5 cycles for an LDIR? Obviously 2 cycles to read the instruction, one to read and one to write. One of the 5's is evidently unused when (--BC)==0, so is it really the case that the z80 reads the (erroneous) next instruction before doing PC-=2 (as one source on the web suggested)? And if so, why 5 and not 4 (since reading EDBO is 4 each)? G __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: Fastest memory transfer (on Sam)
Edwin Blink wrote: The fastest scrollleft code I could think of is the folowing code snippet which should be repeated 9*height times and It's best to write a routine to generate it runtime and fill in the proper SP values. [snip] It's 20% faster and takes 29% less space then LDI's. BTW These timings (and earlier mentioned) are RAM timings when the ASIC is NOT updating the display. Trying to think this through... Given that a contended memory access is 8 cycles, a contended PUSH/POP would be 48 cycles 8 - read &F1 from PC++ 8 - read A from SP++ 8 - read F from SP++ 8 - read &F5 from PC++ 8 - write F to SP-- 8 - write A to SP-- or 24Ts per byte, plus the extra 48 for every 14 bytes transferred ie just under 28Ts per byte(?) IIRC An uncontended LDIR is listed as 21/17 cycles (21 cycles for each except the last ?) - read ED B0 from PC+=2 (4 x 2) read (HL++) (3) write (DE++) (3) BC--, if !0 then PC-=2 On Sam that probably comes up to what, 24? A contended LDIR will be what? 16 - read EDBO 8 - read HL 8 - write DE How much for the BC calculation and the PC--? Does that fit into the 32 T-states? HOWEVER, if you use the ROM LDIR routine (008F), then it comes down to 8 - read EDBO 8 - read HL 8 - write DE 24 cycles, plus whatever the BC/PC bit takes. 28? Obviously when uncontended your push/pop method is best but once the screen draw kicks in it might be worth calling the ROM. This would then be confused by the borders, of course... :) Has anyone tried a comparison on a real Sam? G
RE: Development tools wanted
Bleagh. At least use something with instruction timings in it. http://www.ticalc.org/pub/text/z80/z80time.txt is an example, although bear in mind that the Sam's timing is somewhat, erm, fuzzy, generally :-) - IIRC everything's rounded up to multiples of four in contention time. Actually, what is the timing issue, I don't think I ever really properly understood it... is it every contended memory access is 4 cycles? G From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]Sent: 28 January 2005 14:57To: sam-users@nvg.ntnu.noSubject: Re: Development tools wanted In a message dated 01/28/2005 14:53:15 GMT Standard Time, [EMAIL PROTECTED] writes: I still use the original orange ZX Spectrum manual as a Z80 instructionsreference. I have a version of this as pdf if you want it , or anyone else just email me! regards Steve __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Christmas Present
Stuart Brady wrote: > On Tue, Jan 25, 2005 at 01:36:17PM +0100, Aley Keprt wrote: >> ...but I unintentionally did the similar thing without buying the >> Messanger. As soon as I saw that there is no ZX ROM at Sam, I took >> my ZX Spectrum+, and typed SAVE"rom"code 0,16384, then loaded this >> file to Sam BEFORE starting the MGT/Samco's emulator. This way I was >> able to run much more Spectrum games. :-) > > I didn't know you could run the MGT emulator without the Spectrum ROM, > actually. What do you gain from running the emulator, if you don't > have the ROM? MGT produced an almost-compatible ROM which (since it wasn't Sinclair code) they were allowed to distribute. It ran some (not many) Spectrum games. It also had NMI code, which the Spectrum ROM had to be modified to add (I started working on this to implement my own multi-page emulator, but gave up when I got Lerm SamTape (?)). Geoff __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: "Spectrum on Sam" games at NVG
Gavin Smith wrote: > This is probably a good time to ask people's opinions on including > Speccy games that have been made to run on a SAM, on samcoupe.org - > my opinion is that they are still Speccy games and they should > initially be left out. What do others think? IMO something that's been modified to work on the Sam in a special way (be it music, graphics, disk support or even just to use Sam-style paging instead of 128-style) should be included (in a specific area) because you can't get it anywhere else. G __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Geoff Winkless Scrolly Bars and Bouncy Balls Bemo
Simon Owen wrote: > Geoff Winkless wrote: >> It's on one of the Outlet disks (57?), if anyone has that. > > SBBB is on Outlet 62 (October 1992), as option C on the menu. Blimey... that was fast! >> The only version I've managed to extract from my disks is (I >> think) an old one: it doesn't have a reset screen, and it leaves >> the palette in the wrong state on exit. > > There's no reset screen on this version, Really? How strange, I thought it had. Must be getting confused with BSD... yeah, thinking about it that makes sense. > I couldn't see that on this version when I cycled through them - I'll > send you a copy off the list and let you check! Thanks, that'd be cool. I really must try and grab my disks again, now I have a couple of new floppy drives to try it on... there's a version of Tetris which is still more playable than most and which I could finish off for a fun project :) G __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: NVG/samcoupe.org Accessability Project
Dan Dooré wrote: > I have now completed trolling through GoodSAMC, my collection and > various others from those who have helped me in this endeavour. A big "well-done" is deserved, I think! I'll take a look when I get home and see if I have anything you didn't (unlikely, but you never know). Geoff __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Geoff Winkless Scrolly Bars and Bouncy Balls Bemo
Dan Dooré wrote: > I was browsing Andrew's site and saw this demo with a link to NVG > that I didn't remember seeing when I did the DSKification - > http://www.intensity.org.uk/image.php?i=samcoupe/db/gwdemo.GIF&n=1&max=1 > > This is linked as > ftp://ftp.nvg.ntnu.no/pub/sam-coupe/demos/misc/balls.zip which > although now broken after the NVG re-org, a look in ./OLD/ points to > balls.zip which is actually a PAK file containg this: > ftp://ftp.nvg.ntnu.no/pub/sam-coupe/disks/demos/BallsDemoByGP.zip > which is a different beast altogether. > > Does anyone have a copy of this demo and if so can they bung me a copy > in DSK format. It's on one of the Outlet disks (57?), if anyone has that. 56 is on RomNation and it's not that one, and KeDisk was on 55 and I remember SBBB went on one soon after that. The only version I've managed to extract from my disks is (I think) an old one: it doesn't have a reset screen, and it leaves the palette in the wrong state on exit. Oh, and it crashes on one of the radial equations :( I'm pretty sure I'd sorted those out by the time I gave it to anyone. Having said that, I might just have been that lazy. :-) G __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: How ROM knowns wheter a disk is "bootable"
Frode Tenneboe wrote: > On Thu, 13 Jan 2005 11:31:42 +0100 "Aley Keprt" <[EMAIL PROTECTED]> wrote: >> >> Please read again what I suggested. If you say that Sam ROM reads >> just track 4 sector 1, it means that I AM correct. Yet again, if you >> say that Sam ROM doesn't know about directory, that means I AM >> correct. > > Ah. Sorry. Misunderstood. You are correct, but what wold the purpose > of this byte juggling be? > > Technically, you could also take a bootable disc, erase the samdos2 > file and still have a bootable disc (until something overwrote track > 4 or 5). You could add the DOS sectors to the sector map of another file (one which won't be rewritten, of course). G __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: FpCal Rom Adr.
Z80 wrote: > Hi all, > > I'm having ( for two months now ) a problem regarding SamC rom > routines. I have some programs which work perfectly on Spectrum and > I'd like to port them to SamC. The problem is ( ta d ) while for > Spectrum I have some ROM routines to convert a string to a FpCalc > format, you know.. the Rst28h thingie ;) , ( 5 bytes that is ) for > SamC I haven't found this routine ( something like basic Val$ I'm > interested ). I can push some constants ( like 0, pi, 16384 ) but a > number like 183.28819 .. I really don't know how. If anybody worked > with it some info or sample asm code would be a dream. Sorry for my > bad English, and thanks. > > Zecut0r. Your english is fine! A quick web search for the tech manual gives: http://sam.speccy.cz/os_tech/sam_coupe_tech-man_v3-0.pdf Page 35 (page 40 of the pdf) looks like it might be helpful: JEXPT1NUM (0118H) Syntax check/evaluate a numeric expression. During syntax checking an invisible 5-byte form of any literal numbers is inserted. During run time the result of the expression is left on the floating point calculator stack. JEXPTSTR (0116H) Syntax check/evaluate a string expression. See JEXPT1NUM. JEXPTEXPR (0llEH) Syntax check/evaluate an expression. See JEXPT1NUM. These three routines can be useful in extending the Basic interpreter. HTH Geoff __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: FpCal Rom Adr.
Z80 wrote: > Hi all, > > I'm having ( for two months now ) a problem regarding SamC rom > routines. I have some programs which work perfectly on Spectrum and > I'd like to port them to SamC. The problem is ( ta d ) while for > Spectrum I have some ROM routines to convert a string to a FpCalc > format, you know.. the Rst28h thingie ;) , ( 5 bytes that is ) for > SamC I haven't found this routine ( something like basic Val$ I'm > interested ). I can push some constants ( like 0, pi, 16384 ) but a > number like 183.28819 .. I really don't know how. If anybody worked > with it some info or sample asm code would be a dream. Sorry for my > bad English, and thanks. > > Zecut0r. Your english is fine! A quick web search for the tech manual gives: http://sam.speccy.cz/os_tech/sam_coupe_tech-man_v3-0.pdf Page 35 (page 40 of the pdf) looks like it might be helpful: JEXPT1NUM (0118H) Syntax check/evaluate a numeric expression. During syntax checking an invisible 5-byte form of any literal numbers is inserted. During run time the result of the expression is left on the floating point calculator stack. JEXPTSTR (0116H) Syntax check/evaluate a string expression. See JEXPT1NUM. JEXPTEXPR (0llEH) Syntax check/evaluate an expression. See JEXPT1NUM. These three routines can be useful in extending the Basic interpreter. HTH Geoff __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Dial 0898 299 380 through time
Edwin Blink wrote: > BTW I've also found a SAM Newsletter with the stuff. Anyone remeber > those ? Yeah, think I've got them all in a folder somewhere, along with the newsletters from Enigma's Sam Software Club. G __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: MasterBasic PDF Version 1 [ now ready ]
I can only see the English version... ;) G From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]Sent: 12 December 2004 14:51To: sam-users@nvg.ntnu.noSubject: MasterBasic PDF Version 1 [ now ready ] Hi Folks, Just had time to finnish this, and its ready for download from the Pro-Dos site. http://www.samcoupe-pro-dos.co.uk/sammanual.html [ now looking off a Sam pfd project , what would you like? ] Regards Steve(spt) __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: SDI a nef diskimage format ?
Simon Owen wrote: > It's actually Chris Pile's original Defender disk, which does some > gap-level checking as part of the copy protection. The gap > information isn't stored as part of the disk image, as it's almost > never needed, and would more than double the image size. SimCoupe > actually fakes the raw track data from information it knows about the > sectors on the current track, so it looks pretty authentic in > programs like SAM DICE. One of the ways I was going to do protection (if I'd ever got round to it) was buying a load of really crappy disks and writing code specific for each disk that attempted to format a track I knew would fail - if it formatted correctly it would know the disk had been copied... not usable on high-volume items, but for the low-volume Sam market, it would have been perfectly do-able :) I do remember reading about one company which used to laser holes in their disks at a specific point to do much the same thing, although I don't think this was on the Sam. On a side track (hah), has anyone else found that all their old Sam disks are completely unreadable? Is it likely that I had a drive that, while being in-spec of the other Sam drives, is out of spec enough so that the average PC drive can't read floppies created by it? Or is it more likely that almost every single one of my disks have simply degraded over time? I spent many many hours trying to get Linux to read my Sam floppies using different FDD parameters before giving up and deciding that it must simply be the disks :( G __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: MasterBasic Manual Errors Do you know any?
[EMAIL PROTECTED] wrote: > Q 2. Any errors in the manual to be included as a page at the end of the pdf? > Yes/no I'd say keep as-is for the sake of history, and add an erratum page. Well done for all the hard work, BTW! Geoff __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: SDI a nef diskimage format ?
Simon Owen wrote: > Does the archive need to be a single format for all disks? Or could > the 95% of normal format disks be kept in a simple dumped image > format, with only protected disks using a different format needed to > describe them correctly? Why not a tagged format and tools which can handle both types? As a user I would certainly rather have an archive with a single type of disk. Geoff __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Yaaaayyyy - Sam's 15th Birthday!
Calvin Allett wrote: > 15, before you know it he`ll be dating, haha Hmm. Jokes about Amigas and STd's on the way... G __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Sam's 15th Birthday!
Colin Piggot wrote: > Well, December 2004 see's the 15th Birthday of the Sam Coupe! Did > anyone here receive their Sam in December 1989 when they were > released, and did it live up to your initial expectations? Yes and yes. I'd spent pretty much all my pennies from my paper-round and was well chuffed when it arrived. Business Post. I remember being disappointed about the disk not working but then going through the demo tape and being utterly gobsmacked when the screen grab of the astronaut came on screen. Simpler times :) Geoff __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: [FJV-59346]: Hosting question - urgent please!
Gavin Smith wrote: > The email below is from Catalyst2, the web host I'm going to use for > the archive. Sounds spot on. [snip hosting stuff] I'm impressed: kudos to Catalyst2. G __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: SAM Software Archive
Gavin Smith wrote: > By the way, I still plan to get the domain sorted tomorrow evening so > if anyone has an opinion on what domain they'd like us to use, shout > out today or tomorrow - it looks like samcoupe.org is in the lead at > the moment. ? I vehemently believe this to be the wrong approach. People _will_ remember the wrong thing and type .com. Of course Colin could put a link to the other site from his, but that just tends to make people think he's trying to get free advertising by using the .com, even though it's actually the other way around, and will reflect badly on him. Can we have some sort of proportional-representation vote-transferral system? :) worldofsam.org would still be my preferred option, followed by samcommunity.org. I'd also be happy with samarchive.org or similar - in fact, anything _except_ samcoupe.org :) [usual disclaimer: I'll go with the majority verdict, even if it's wrong :) :) :)] G __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: overclocked Sam programs [was RE: ORSAM show report]
Simon Owen wrote: > SimCoupe does have some convenience features that aren't true to the > real machine, such as turbo mode, fast disk access, fast startup, and > auto-booting. Adding support for fixed variable speeds (25%, 50%, > 200%, ...) probably falls under the same category, and is something > I've got on the ToDo list for a couple of people. Allowing variable > CPU speed is a much greyer area, unless it was done in a > peripheral-type way like both SAM accelerator prototypes. Yeah, it would be quite a challenge (<<-- understatement) to try to introduce the same contention issues that Cookie talked about with simcoupe :) G __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: SAM Software Archive
Gavin Smith wrote: > Quoting Geoff Winkless <[EMAIL PROTECTED]>: >> What sort of bandwidth do people think it would use? I already have >> a shared (with a few old uni mates) linux host (on which I have root >> access) and would be happy to host it if we're expecting a gig or so >> downloads a month - that much we can absorb into the spare bandwidth >> we have, if it's more I'd have to discuss it with the others. > > I had a long think about hosting and our options and ways of doing it > on the cheap but in the end I thought it would be nice to spend a > fiver a month and get our own meaty bandwidth etc and not worry about > taking advantage of other people's generosity or the site suddenly > going down etc. WRT bandwidth: currently the whole machine is only using 5GB out of the monthly 30GB we've paid up-front for, however I wouldn't want to take too much of it month-on-month because that wouldn't be fair on my mates :). The point is that (barring links from geek sites like slashdot or theregister) it's not going to be a volume site, however much we'd like to think otherwise, so 5GB per month is way more than you'd need month-on-month (once you get over the initial excitement). However you always pay for more bandwidth up-front than you need because if you go over it tends to cost more - this way we share the buffer with a few other sites (we have about 10 at the moment, and they're all fairly low-volume). The other thing about the service we have is that excessive bandwidth doesn't stop the site working - I'd just have to cough up for the extra cash, and even then it's only £1 per GB. The only problem I have with services like catalyst2 (the site you mentioned) is that you don't have full control: it's a hosted service, so you have the restrictions of what you can do with it. I have full ssh root access so if (eg) you want to run some bizarre forum software you don't have to argue with a clueless support guy for an hour. Further, if one of my sites goes down I know it's either down to me to fix it, it's a hardware problem or it's the internet (and since it's in telehouse that would generally mean the whole UK web is screwed :)) You also have the advantage that the people who administer the machine have a combined unix and website admin experience of about 40 years, the other two guys are both sysadmins at university (with tens of unix servers to run) and I was admin for an ISP for a fair while. Finally the people actually doing the hosting are clueful too: check out http://www.bytemark.co.uk/hosting/virtualmachine/index.html (yes, it's a virtual machine but that's caused us 0 problems so far). If you do decide to go it alone you could do a hell of a lot worse than one of their £150/year packages (some people might remember Matthew Bloch from the days of the Acorn Arcade BBS) All this is a Good Thing when it comes to hosting software of slightly unknown legality: hosted services tend to be a bit more trigger-happy when it comes to removing sites which have potential warez. > I wouldn't think you're trying to take over, I would really hate it > if people thought of this as my pet project because I honestly think > it's 100% a sam-users thing. :) OK, then I should have written the caveat to everyone :) - my point is I don't want to be seen as imposing my thoughts on others. Anyway, the offer's there, I shan't mention it again unless asked - I have no axe to grind, it'd only mean work for me after all :) G __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: SAM Software Archive
Dan Doore wrote: >> A World Of Spectrum style semi-official archive for SAM software, >> housed on the web and built by the members of sam-users. > > Bang on. > > BTW another vote here for samcoupe.org While I agree in principle that samcoupe.org would be the best for the site I think that as Colin has samcoupe.com it will serve to confuse. My vote would be for worldofsam.org for the reasons people already mentioned. What sort of bandwidth do people think it would use? I already have a shared (with a few old uni mates) linux host (on which I have root access) and would be happy to host it if we're expecting a gig or so downloads a month - that much we can absorb into the spare bandwidth we have, if it's more I'd have to discuss it with the others. Note to Gavin: I'm not trying to take over here; if you'd rather host it yourself I won't be offended :) Geoff __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: SAM software archive
Gavin Smith wrote: > Definitely, although I'd like to sort of integrate the stuff into the > archive in terms of listing it with details such as author name, > publisher, year and also screenshots - where there would normally be a > download link, it will just say something like "Distribution Currently > Denied". Can I ask that the wording is a bit kinder? You're making it sound like people are being unreasonable, which is something that is (IMHO) bad form. Something like "the author has requested that this work is not distributed" and put some contact details for further info. It basically says the same thing but it's what I was talking about before about respect. G __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Hi
Kevin Cooper wrote: > Just joined the list at the start of the week, been busy having a look at what you're upto... Hello! > Am starting to get all nostalgic now, thinking about those many hours > I spent with Sam back in the early nineties. I miss it... that real > sort of big community feel it had to it. I think that's what we all hanker after... coding on PCs is so much easier but just doesn't have the same feeling. Welcome to the list, anyway! Geoff __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Days of Sorcery
Johnna wrote: > So I say - Publish and be damned! Let's get a website up and running > and dump EVERYTHING we've got on there that is SAM related and then > maintain it as a homage to what was, once, a great machine. Nobody > else is going to do this. We are almost the last bastions of the SAM > World, even the original manufacturers of the machine show no > particular interest in it anymore. > > Or of course, we could wait until the natural copyright expires in > around 65 years and do it then. Most of us will be dead, and those > who aren't will not care any more. > > But sitting around and talking about doing something, although almost > a great tradition of the Sam scene, will only end up with us losing > the last remainging interest that reamins in the machine. But one of the great things about the Sam was (and is!) the respect and sense of community which the users showed to each other. By insisting that we check with the original authors we are maintaining that level of respect which I for one have no wish to destroy. Geoff __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: overclocked Sam programs [was RE: ORSAM show report]
Colin Piggot wrote: >> It occurred to me that with SimCoupe we could overclock the machine >> and code up stuff that wouldn't have been possible on the 6MHz Sam >> (except possibly with the accelerator board, of course!). Do people >> think this destroys the heritage of the machine or is it something >> they'd be happy to see (especially if we did restrict it to what's >> possible with upgraded hardware)? > > Hmmm... the temptation would be there to run SimCoupe at higher > speeds, and yes great things could be done... but it would lose the > feel of the real machine along the way. I don't know - I agree that the feel of the machine would change if you started cheating by adding in direct access to PC hardware or something to get better graphics or sound, but if it's literally just the same but faster (say equivalent to a 12MHz z80) and is achievable with an expansion board on the original hardware, it's no different to having an emulator with support for a hard disk, or a built-in debugger (*cough*, Simon). > What happened to it ... long forgotton in the land of projects not > finished... Unfortunately along with Simon and Martin's other > projects - the MultiROM, the MiDGET, and dare I say it ... oh go on > then. Statues of Ice! Heh. If Andrew's site comes back up in the near future I'll have a play with pyz80, then Statues might still see the light of day :) :) :) Alternatively I might just write the shoot-em-up I always wanted but couldn't be bothered with... It's up now, actually. Now I have to get python :( G __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
overclocked Sam programs [was RE: ORSAM show report]
Howard Price [mailto:[EMAIL PROTECTED] wrote: > BORING! Everyone's sound on this list, and I can get > bickering off any old net chatroom. That'll do now. Apologies to all, hadn't intended my light-hearted comment to offend, and Howard's absolutely right of course. On to Sam stuff... It occurred to me that with SimCoupe we could overclock the machine and code up stuff that wouldn't have been possible on the 6MHz Sam (except possibly with the accelerator board, of course!). Do people think this destroys the heritage of the machine or is it something they'd be happy to see (especially if we did restrict it to what's possible with upgraded hardware)? And on the subject of the accelerator board, I remember Cookie showing one running Lemmings at the second Gloucester show that someone (can't remember ... was it Nev? don't think so) had built... what happened to that? (I also remember spending many hours the night before flicking through the z8000 manual that he'd got hold of in a kind of 6-year-old-at-christmas glee, but that's another story altogether) Geoff __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: ORSAM show report
Then why exactly did you send it, if not to reflect some glory on yourself? Would you rather we thought you did it to belittle Wolfgang and his efforts? Bob Brenchley once described me as a "stupid demo coder" and it merely made him look small (no mean feat...). You can call me "some idiot" if you like but in the same way it only serves to detract from your argument. What you wrote (originally) left a sour taste in the mouth, which is a real shame because I'm sure you put Wolfgang up with no ulterior motive. My email was intended as a gentle nudge to point out that what you wrote seemed a little petty, I'm sorry that you didn't see it that way, perhaps a liberal sprinkling of smileys would have been useful? Geoff From: Leonard Bennett [mailto:[EMAIL PROTECTED] Sent: 17 November 2004 18:03To: Sam users groupSubject: Re: ORSAM show report Somehow I was expecting some idiot would come up with this... - Original Message - From: Geoff Winkless To: sam-users@nvg.ntnu.no Sent: Tuesday, November 16, 2004 11:33 AM Subject: RE: ORSAM show report What do you want, a medal? G From: Leonard Bennett [mailto:[EMAIL PROTECTED]] Sent: 15 November 2004 11:08To: sam-users@nvg.ntnu.noSubject: Re: ORSAM show report I would just like to point out here that Wolfgang was staying with me as my house guest here at Welwyn Garden City from Thursday 4th to Tuesday 9th. All his expenses were paid by me, even the taxi fares from and to Stansted, and the train/bus fares to Norwich. Doesn't seem so astounding now, does it David S-S! Len Bennett__This email has been scanned by the MessageLabs Email Security System.For more information please visit http://www.messagelabs.com/email __ __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: ORSAM show report
What do you want, a medal? G From: Leonard Bennett [mailto:[EMAIL PROTECTED] Sent: 15 November 2004 11:08To: sam-users@nvg.ntnu.noSubject: Re: ORSAM show report I would just like to point out here that Wolfgang was staying with me as my house guest here at Welwyn Garden City from Thursday 4th to Tuesday 9th. All his expenses were paid by me, even the taxi fares from and to Stansted, and the train/bus fares to Norwich. Doesn't seem so astounding now, does it David S-S! Len Bennett __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: hello (again)
Geoff Winkless wrote: > I -thought- it had all gone a bit quiet... my NTL account is no more, > and they've finally stopped forwarding the email :( > > Anyway, hello, have I missed anything? Apparently not :) Geoff __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
hello (again)
I -thought- it had all gone a bit quiet... my NTL account is no more, and they've finally stopped forwarding the email :( Anyway, hello, have I missed anything? Geoff __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: SimCoupe 0.90 beta 10
25 March 2004 00:54, Simon Owen wrote: > You're _way_ over-complicating things! It was simply looking for the > DX version number in a registry key that didn't exist in older > versions of DirectX. Failing to find the version key it assumed > DirectX was not installed. > > Here's the NSIS function I was using for the old check (yes it is > wrong, and no I didn't write it): > http://nsis.sourceforge.net/archive/nsisweb.php?page=407&instances=0,110 It's kind of like the difference between getting the browser id in javascript and testing for the existence of the object you want to use: the first is likely to work (assuming the version id is correct) but the second is guaranteed and a) more flexible and b) much "nicer". If you check for the existence of the object you want, you know that, even if a change is made to directx so that your version check will not work, as long as the object exists then your check will be valid. G __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: NVG
23 March 2004 17:17, Edwin Blink wrote: > Can anyone access NVG ? 'Cause I Can't. > > Edwin Me neither. Geoff __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: SimCoupe 0.90 beta 10
06 March 2004 03:46, Simon Owen wrote: > If anyone's interested, I've put together updated SimCoupé builds for > Win32 and DOS (plus source for other platforms). They're available > for download from: > http://homepage.ntlworld.com/simon.owen/sam/simcoupe/ > > It's still a beta release, but is very close to what will go out as > version > 0.90. The Win32 version should be complete, and the SDL/Allegro > versions just need some minor additions (mainly the New Disk dialog, > unless I've forgotton something else). The documentation hasn't been > updated yet, but I hope you can feel your way around - e-mail me if > you've any questions, particularly if you are having problems. Hmm. The win32 installer fails on this NT box - complains about directx >=3 being needed even though v5 is installed. G __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: English
On Saturday 13 Mar 2004 16:08, Simon Cooke wrote: > We're all friends here... > > Realization: U.S. English. > Realisation: U.K. English. Oxford tends to stick to the -ize spellings (or so Inspector Morse taught me). However in general the above is true. G
RE: SAM populair on ebay
05 March 2004 15:00, Chris White wrote: > Well the first looks good and going well, the seconds is still at > nothing , I cant translate it, but if looks like the box, wont be much > good (unless they only selling box) It is only the box - I checked with the seller. G __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Colin Piggot Namechecked...
15 January 2004 05:09, david wrote: > The Amiga? Wasn't that some second rate American machine with crap > midi software? Uhh, no. It was the first-rate games machine which also had a decent multitasking OS and some rather nice music apps (Bars & Pipes springs to mind). Compared to the Amiga the Sam was an abject and total failure as a Spectrum emulator (the Amiga does this very well in software, although admittedly slower on the A500 without a processor upgrade) a games machine (no comment needed, I think) and as a business tool. The Amiga was more expandable, more programmable and vastly superior in hardware. Believe me, I loved playing with the Sam and it was an important step for me as a programmer but really the Amiga was in a different league. Actually no, it was playing a whole different game. Geoff This email has been scanned for all viruses by the MessageLabs Email Security System. For more information on a proactive email security service working around the clock, around the globe, visit http://www.messagelabs.com
show tomorrow
Hi Guys So who's going to be at the NEC tomorrow? I was thinking about heading down there around lunchtime, should we all meet at Colin's stall? Geoff
RE: Norwich Spectrum and SAM Show (ORSAM 2003)
07 November 2003 14:09, Wolfgang Haller wrote: > http://www.womoteam.de/SAM/Norwich_Pics_2003/norwich_pics_2003.html one mistake, you've misnamed Si Owen as Si Cooke! > For me it was an interesting meeting. Sadly I noticed to have miss > some personal connections as with Mr. Richardson and Geoff Winkless. We did exchange a few comments but were never properly introduced... > If I have them on any pic then please tell me. I'm in norwich24.jpg, black leather jacket and white t-shirt, and talking to Dave L in norwich16.jpg Cheers Geoff This email has been scanned for all viruses by the MessageLabs Email Security System. For more information on a proactive email security service working around the clock, around the globe, visit http://www.messagelabs.com
Re: Norwich Spectrum and SAM Show (ORSAM 2003)
On Wednesday 05 Nov 2003 10:43 pm, Tarquin Mills wrote: > Does anyone know > where there is diagram of the motherboard to help me get Nev's boards > working? The tech manual is on NVG, if I remember correctly that has the circuit diagrams in it. Geoff
RE: Norwich Spectrum and SAM Show (ORSAM 2003)
01 November 2003 17:11, Nev Young wrote: > pictures without words at > > http://www.nfy53.demon.co.uk/sam2003/ More pictures with some somewhat irreverant (should that be irrelevant?) words at http://geoff.dj/sam/ Click on the thumbnails to get the full-size pictures as they came out of the camera. Thanks to everyone who got involved, it wasn't exactly a roaring success but I had fun, in a bizarre sort of way. Geoff This email has been scanned for all viruses by the MessageLabs Email Security System. For more information on a proactive email security service working around the clock, around the globe, visit http://www.messagelabs.com
