Re: Pro-DOS v2.0 (CP/M 2.2) released
I'm late to the party but congratulations from me! Now we can all more easily word process just like George R.R. Martin. I've been reimplementing CP/M for a non-Sam platform on and off; as it's also now relevant here can you comment on which CP/M reference resources you'd recommend? There are some voluminous pages near the top on Google but they all seem to leave certain ambiguities lingering. Presumably you've got, or once had, some real, physical documents? On 31 May 2014, at 10:31, the wub wrote: > Great work Chris, I'm another person looking forward to playing > Hitchhikers on the Sam. > > Thanks! > > > On 5/30/14, Chris Pile wrote: >> The date on the letter/instructions I sent to Brian to accompanying the >> disks >> was March 1993. So, yep, 21 years old! They were cheap bulk-buy >> non-branded >> disks too, so it's amazing the data survived! >>
Re: HxC and Sam Coupe
What's the software like for the HxC? Can you just copy floppy images onto SD card or is there some Windows blob to convert to a more direct flux transition sort of representation? On 20 May 2013, at 11:37, Colin Piggot wrote: > Graeme wrote: >> So just to follow up, Colin made me the extended adapter board and my >> HxC is now working nicely on with the Coupe. > > Excellent! Good to know you've got it set up and working. > > Colin > Quazar : Hardware, Software, Spares and Repairs for the SAM Coupé > 1995-2013 - Celebrating 19 Years of developing for the SAM Coupé > Website: http://www.samcoupe.com/Twitter: @QuazarSamCoupe >
Re: SimCoupe / Trinity
I've no personal opinion beyond than that Colin's decision should be respected — but the law graduate part of me couldn't let it lie so, for the sake of playing devil's advocate: (i) people would be more likely to buy the hardware because it would be more likely that developers had produced software for it; and (ii) in any case they'd be no less likely to because if they don't buy hardware that is emulated then they don't have a Sam to plug it into. I would phrase the other argument more that: (i) emulation reduces the perceived value of hardware, so will either push prices down or affect sales; and (ii) in any case is a fundamentally different experience from that Colin intended, so could accurately be described as an unapproved gross distortion of his efforts. Which is naturally not something he'd want. On 3 May 2013, at 08:42, Adrian Brown wrote: > But you have to look at it from the other point of view. It takes a lot of > time and money to develop hardware. If it was readily available on > emulation why would anyone buy the hardware? > > -Original Message- > From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On > Behalf Of Marcos Cruz > Sent: 03 May 2013 15:25 > To: sam-users@nvg.ntnu.no > Subject: Re: SimCoupe / Trinity > > En/Je/On 2013-05-02 23:09, Stefan Drissen escribió / skribis / wrote : > >>> Sorry Stefan, I'm still against my hardware being emulated in >>> SimCoupe. > >> That's a pity, it's your right of course, but I think you are >> preventing your work from flourishing in a larger (emulated) audience. > >> Allowing emulation may get some odd sods, myself included, wanting to >> write something for it, resulting in enough momentum for it to become >> interesting for a real SAM user, resulting in a sale for you. Sounds >> like egg and chicken basics to me. > > I agree with you, Stefan. > > Creating software and hardware for the real SAM is great and desirable, but > emulation is the way most people can use, program or even meet a SAM. > > In my opinion, emulating a good interface is an avail for its seller and for > the real machine users, because the interface becomes potentially more > useful, and more desirable. > > Marcos > > -- > http://programandala.set >
Re: MGT-Samco newsdisks not downloadable
It's a shame we don't know who owns them though; I'd be willing to pay. On 9 Apr 2013, at 09:48, Mike Nicholas wrote: > OK many thanks for the clarification. > > -Original Message- > From: Adrian Brown > Sent: Tuesday, April 09, 2013 9:29 AM > To: sam-users@nvg.ntnu.no > Subject: RE: MGT-Samco newsdisks not downloadable > > Only another 25 odd years and it can be released ;) > > -Original Message- > From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On > Behalf Of Tennebø Frode > Sent: 09 April 2013 07:40 > To: 'sam-users@nvg.ntnu.no' > Subject: RE: MGT-Samco newsdisks not downloadable > >> For sentimental value I was trying to download the sam newsdisks: > > : > >> But it keeps coming back with an error saying the source files cannot >> be read. > > These filese have been put in a "denied" state due to someone at one time > have requested them removed for download. I should of course have made a > note on who and when, but that never happened. Who owns the rights to this > software now is not clear to me, but unless someone with a bit of authority > on the issue comes forward and approves I'm relucantat to just release them. > This also goes for a few other pieces of SAM Coupe software visible, but not > downloadable, from the archive. > > -Frode >
Re: SAM / +D Help needed
I got as far as discovering that "SAM Coupé diskimage Manager v1.12 by Edwin Blink" would allow you to liberate the files from the Sam disk image to a Windows PC; there must then be a tool for throwing them onto a Spectrum TAP or DSK. On 23 Mar 2013, at 15:32, "da...@properbastard.co.uk" wrote: > Doesn't look like anyones able to help me with this. > > Never mind - thanks anyway. > > I'll delete it as it was a pile of shite anyway - like most things I ever did > for SAM. > > > > Quoting da...@properbastard.co.uk: > >> Very good point :-) >> >> Quoting Leszek Chmielewski : >> >>> Am 28.02.2013 18:09, schrieb da...@properbastard.co.uk: So I guess this is a no then? Quoting da...@properbastard.co.uk: > I was wondering if anyone with PAWS (Professional Adventure Writing > System) knowledge could help me try and transfer a game from SimCoupe DSK > format to one that would work on the Spectrum? > > I've a game which was originally written for the Spectrum around 1988 (if > I remember right) which I had managed to convert for the unreleased Blitz > 9 - but I'm not sure how to go about getting it to work on the Spectrum > again. > > It's something I'm thinking could be worth adding to the WOS archives... > or perhaps at least dusting off for the crap game compo :) > >>> I'm not familar with PAWS, but I just want to suggest to change the subject >>> because many of us got mails from Doctor Ugandunga with same subject >>> "assistance required", asking us to help him to bring the sum of 55 Million >>> US$ out of the national bank of Uganda, and offering us 40% of this sum for >>> our Assistance. >>> Nobody reads mails with the subject "Assistance >>> required/needed/requestet"... >>> >>> LCD >>> >> >> >> > >
Re: Second Hand Sam Coupe Wanted
To be fair, what are the odds of a random Sam's drive still working anyway? On 3 Aug 2012, at 17:41, Wayne Weedon wrote: > On 03/08/2012 15:50, Rich Mellor wrote: >> Good afternoon all, >> >> One of my customers in Brazil has asked about getting hold of a Sam >> Coupe - does anyone have a working one ready for sale? > > Here's one! > > "http://www.ebay.co.uk/itm/VERY-RARE-VINTAGE-MILES-GORDON-TECHNOLOGY-SAM-COUPE-VGC-BOXED-/290699881242?pt=UK_VintageComputing_RL&hash=item43af102b1a"; > > LMFAO!No Disk drive? > > I got a boxed one in the attic just like that, not for sale though YET! > > Wayne..
Good resources for learning about the ASIC?
I'm currently partway through The ZX Spectrum ULA: How To Design a Microcomputer, which is the book partly researched by photographing and reconstructing the exact IC layout of the Spectrum's ULA. So it goes into a lot of detail about how ICs were produced in general, the nature of ULAs, the Spectrum's design constraints, how they therefore ended up laying things out and all that sort of stuff. As someone who has previously looked no lower than product data sheets it's fascinating. Does anyone know of any similar sort of details about the Sam's ASIC? Presumably it's a similar process — application-specific interconnects added to a generic, previously manufactured base — but benefitting from seven years of advances in density? Though the Sam's design process seems to have been quite extended, so maybe they used some other process? I guess nobody has the resources to have photographed one but what documentation do we have? Google's not turning much up.
Re: BorderTron 3000 - SAM Coupe Edition
Sounds great! As a long-time OS X user and programmer, is there anything can do to help there? On 4 Jun 2012, at 17:32, Chris Cowley wrote: > I've done a SAM-specific version of my little BorderTron Spectrum > utility (an editor for drawing graphics and text in the border area of > the Spectrum and various Spectrum-like machines). As this version is > SAM-only, it isn't restricted to the limitations of the speccy, so it > gives a greater horizontal resolution (16 pixels, compared to 24 on > the speccy), and allows the use of any of the 16 CLUT entries in the > border. > > This version also uses line interrupts to position the bottom border, > removing the idle-loop needed by the speccy version. This leaves >> 8 cycles free per frame when images are displayed in both the top > and bottom borders, with no display-sync issues, so it should be > entirely feasible to have border graphics active during, say, the main > loop of a game or demo. > > You can fetch it from:- > > http://freestuff.grok.co.uk/bordertron3000/sam/ > > -- it's a Windows app at the moment, but I'll do an OSX port just as > soon as I work out how the hell binary resource files work on a Mac. > The Windows version should work fine with wine on linux and MacOS > anyway. It spits out ASM files if you want to include/hack the results > in your own projects or DSK files if you just want to see your results > on an emulator or the real thing. > > Hope it's of some interest. Thanks are due to Simon Owen for the > various pointers-in-the-right-direction he's given me with this. > > Best wishes, > Chris.
Re: Quick attempt at a scroller
I read your blog a few days ago I think; it's Splitting Images isn't it? Are you going to update the images or are (slightly) younger people like myself going to have to find out what people like David Owen looked like? I'm working on sprites at the minute. Mostly mentally as my schedule requires, but I'm just not sure what's realistic to attempt. If I have, say, 40% of a frame to spend on it, how many sprites, and how large, is it realistic to expect to be able to draw and un-draw? Open middleware is definitely the thing to aim for. Besides anything else, it'll make the assumptions and limitations plainly visible. On 17 May 2012, at 22:36, Balor Price wrote: > No apologies required, looks very good to me. So if you're not in a > position to turn it into a full game, would you consider turning it into > a bit of middleware?? A bit cheeky I know but I'm sure it would find a > good home somewhere, probably for many. I made some experiments with > 'full screen' scrolling ages ago but tbh I didn't know what I was doing > because the project was too large, here's a demo I found: > http://scenedamage.com/cookingcircle/Random/AtomManBackup.dsk > > I had a good time doing my last game and I'm halfway* through another > one, having fun! Developing with a cross-compiler/tools really makes a > fantastic effect on productivity, and your tiles displayer/scroller > sounds the business. If you improve the algorithm, anyone using the > routines would get a instant upgrade... > > I believe I am rambling. > Howard > > > *OK, 20% > > On 17/05/2012 00:23, Thomas Harte wrote: >> Apologies to all; I don't mean to treat this list as my own personal >> development blog. However, here's a rock steady 50Hz, full-screen >> rendition: >> >> http://www.clocksignal.com/dropbox/scroller-fullscreen-50Hz.dsk >> >> There are two versions on there and some quick relevant notes. Takeaways: >> >> • the border masking is overdraw and I'd rather fix the problem by >> just not drawing incorrectly in the first place; >> • that being the case, I've only properly profiled the unmasked >> version, and found it takes no more than 60% of the available CPU time >> per frame in its current state. >> >> >> On 15 May 2012 12:39, wrote: >>> It's very cool to see scrolling that quick and smooth. :-) We just need >>> someone to use it in a game now!! >>> >>> >>> Quoting David Sanders: >>> On 15 May 2012 11:32, Thomas Harte wrote: > Or, more likely, the sad realisation that I can't scale the thing to a > proper game is fast approaching... > > For the record, this is it mostly at 25fps, running (essentially) full > screen with black guttering to hide the edge jittering of yesterday: > > Indeed, but we can dream eh? That is indeed some of the smoothest, fastest full-screen scrolling I've seen on the Coupé to date though :-) >>> >
Re: Quick attempt at a scroller
No, there's no deltas in that sense. I just mean that I've got two routines — DrawBlock and DrawBlank — each of which draws a whole tile at (hl) and then returns. Betraying my dense level of thought, they both look essentially like this: ld (hl), b inc l ld (hl), c inc l ... etc etc ... A quick mental calculation suggests I could go full screen again if I switched to subverting the stack pointer. I wrote both by hand for expediency, so it's no surprise they're suboptimal. I had a go with drawing on the half-byte too for a proper pixel scroll but the read/modify/writes killed performance (or, rather, my attempt at them did). I guess either 16x16 tiles (for half as many shared borders) or a vertical scroll would be potential solutions; a vertical scroll would also fix my clipping without any trauma, I guess — I can easily spare gutter space on either side. I think it'd be nice to go full screen and properly clipped one way or the other just to prove the point; I'm not sure I have your sort of willpower for finishing a whole game beyond that. Though if it was a simple run and jump, I guess there wouldn't be that much to it? On 15 May 2012, at 01:10, Balor Price wrote: > Nice! > > When you say the tiles are 'precompiled', have you used a sprite builder > to print the deltas? If so, I'm confused about the left-hand clipping > if there's no real scrolling involved. Surely you're not printing all > those tiles each frame? > > Howard > > > On 15/05/2012 00:32, Thomas Harte wrote: >> It's exceedingly rough and a pretty simple effect that I'm sure has >> been exploited a hundred times before but I thought I'd throw it up as >> is as my part in maintaining the fantastic momentum we've had lately. >> >> http://www.clocksignal.com/dropbox/scroller.dsk >> >> It's explicitly not a mere demo effect; adding some sprites and making >> a full game is a definite possibility, though you'd probably want to >> drop to 25fps — there's loads of memory free even on a 256kb machine >> and it's a full, genuine Mode 4 display. The map itself is just an >> array of bytes in memory, so there's no real magic there and no huge >> footprint. The workflow is based on a cross-platform map editor called >> Tiled so that's easy to manage. >> >> Beyond my painful lack of artistic ability there's no reason why it >> need use only one tile. Ditto for proper clipping at the edges (which, >> because the tiles are precompiled, would cost more RAM but not really >> any more processing). >> >> It was full screen until the last minute, when I discovered that some >> sections of the horrid little map I've hastily scribbled were a little >> too slow. As you'd expect on a Sam, the trick is painting only where >> you need to so level design affects speed in a less obvious manner >> than being directly tied to screen area. >> >
Re: XOR now completed!
Oh! And all I had to do was let the title screen sit there for a bit and it would have told me for itself! I must be a very infuriating user. I'll cough to having made the Wikipedia changes if it'll go any way to paying you back. On 29 Apr 2012, at 10:05, Balor Price wrote: Thanks Rob! And thanks to whoever updated the Wikipedia pages to mention my little conversion. Well, the UK2 DDOS seems to have been sorted now, so I've put the URL back to www.cookingcircle.co.uk now. The graphics were first copied pixel for pixel from the speccy version and then souped up a little, but it was just Flash I used. Both fonts are variable width to the pixel (not byte), which is nice to look at but not very impressive when you see I just saved the fonts twice, one version scrolled one px to the right! :D You're right, the map algorithm mirrors the speccy one - ie if you haven't collected any pieces of map, you just get a blank screen when you try to view it. *Thomas, *Cursor Up should toggle the map/play view. It works on Sim Coupé bnut I haven't got access to a real SAM to check it on. Thanks for the feedback Thomas - I think I'll revisit the front end to make it clearer. Originally there was even less help than I put, but times change. Howard * *On 29/04/2012 17:02, the wub wrote: Seems to work fine for me, not come across any bugs yet... The map screen only has something to see if you've collected map pieces otherwise it's just a blank screen, maybe this was the problem? It's still as frustratingly brain twisting as ever and the presentation is way better than the speccy version! I'd be interested to know if that's all your own work or have you based this on a 16-bit version? All in all, this is definitely going to be booted up every time the Sam comes out to play! Thanks again! Rob.
Re: XOR now completed!
I can't get any screen to come up at all, map pieces or no. What key am I meant to be pressing? On 29 Apr 2012, at 09:02, the wub wrote: > Seems to work fine for me, not come across any bugs yet... The map > screen only has something to see if you've collected map pieces > otherwise it's just a blank screen, maybe this was the problem? > > It's still as frustratingly brain twisting as ever and the > presentation is way better than the speccy version! I'd be interested > to know if that's all your own work or have you based this on a 16-bit > version? > > All in all, this is definitely going to be booted up every time the > Sam comes out to play! > > Thanks again! > > Rob.
Re: XOR now completed!
The way I see it, it's a little bit like Repton without even its limited action elements and it gains a bunch of possibilities from having two player characters. Though they appear to have exactly the same characteristics, at least so far. On 29 Apr 2012, at 02:13, "Aleš Keprt" wrote: > Don't cry, I don't understand the game at all. ;-) > Aley > > -Původní zpráva- > From: Thomas Harte > Sent: Sunday, April 29, 2012 12:39 AM > To: sam-users@nvg.ntnu.no > Subject: Re: XOR now completed! > > I'm not sure I understand the game correctly. > > * either the replay function doesn't work correctly, or it doesn't do > what I think it's meant to. Having just failed miserably to complete > the first level I let it give me a replay but if you believe that then > I never switched shield, spent a lot of time just pressing 'up' and > 'down' and apparently figured out the key to view the map. Which, try > as I might, I can't. Once it was showing me the map there then > appeared to be no way out short of resetting the machine. > * completing the first level appears just to take me back to the title > screen, at which point pressing space takes me back to the first > level. > > I'm forced to conclude that I'm being a dunce somehow. Any tips? > > On 26 April 2012 03:14, Simon Owen wrote: >> On 25 Apr 2012, at 21:29, Aleš Keprt wrote: >> >> It says: Domain http://cookingcircle.co.uk/ not found. >> >> >> It was working yesterday morning but it's now broken for me too. I wonder >> whether it's was caught up in the UK2.net issues from yesterday, due to >> the >> DDOS. >> >> This should work in the meantime: http://cookingcircle.tumblr.com/ >> >> Si >> > > - > Mgr. Aleš Keprt, Ph.D. > private: a...@keprt.cz, www.keprt.cz > office: Moravian College / Moravská vysoká škola Olomouc, ales.ke...@mvso.cz >
Re: Nyan Cat
That's exactly the build system I use, except that I'd managed to misplace my copy of dos. A quick call to open at the end and I'm straight into Sim Coupe, or at least I used to be. The SDL you've linked with appears to be broken under 10.7 in some ways, especially relating to the way the new OS supplies help in restoring sessions, but I'll send a bug report properly and privately when I've had a chance properly to gather evidence. Re: Samdos, is it definitely legal for redistribution? I thought we had explicit clearance but I notice that it's 'not yet approved' on World of Sam. On 23 Apr 2012, at 09:30, Simon Owen wrote: > On 23/04/2012 16:16, Tommo H wrote: >> Vaguely related: does anyone know where I can get hold of Sam dos as a >> binary blob, outside of a disk image, for the purposes of being able >> to assemble things conveniently? > > Most of my SAM projects on GitHub should include samdos2. They also use > pyz80's -I option to add it to the output image before the > auto-executing code file. That's usually plenty for development, even > if I manually add a BASIC wrapper later for the release. > > Si
Re: Nyan Cat
The graphics are no problem whatsoever but the sound would be completely beyond me. Listening to the original (non-8 bit) version shows the song to have a vocal so if that weren't the case I'd probably do the graphics in 4x4 blocks in Mode 2 and get that whole footprint down to 10kb or so, then spend everything else on music. Even then I assume someone would need to come up with a MOD-style version of the track... Vaguely related: does anyone know where I can get hold of Sam dos as a binary blob, outside of a disk image, for the purposes of being able to assemble things conveniently? I can find disk image file extraction tools for Windows only, making them quite useless. On 23 Apr 2012, at 08:07, Andrew Park wrote: > I wonder if this will spawn several renditions of a sam version i'm going to > give it a go too :-) > > Andy > > > -Original Message- > From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On > Behalf Of Aleš Keprt > Sent: 23 April 2012 02:06 > To: sam-users@nvg.ntnu.no > Subject: Re: Nyan Cat > > I analyzed the original video - the whole animation consists of 12 frames > only. So this part is easy. :-) Aley > > -Původní zpráva- > From: Aleš Keprt > Sent: Monday, April 23, 2012 2:42 AM > To: sam-users@nvg.ntnu.no > Subject: Re: Nyan Cat > > I think normal mode 4 + normal music would be OK. I would rather see it > finished in basic variant then to read 100 mails on theory what can be done. > ;-) > I believe mode 4 is achievable. It is small, it is repeated and it seems to > me that all states of the cat can fit into a few screen pages so we would > draw just stars. Plus standard music, samples aren't needed for this. > > So who is going to do it? :-))) > > A. > > -Původní zpráva- > From: Andrew Collier > Sent: Sunday, April 22, 2012 10:57 PM > To: sam-users@nvg.ntnu.no > Subject: Re: Nyan Cat > > Yeah, 4-pixel squares in mode 2 would be easy enough. > > An authentic facsimile in Mode 1 would be tricky as there are squares with > more than 2 colours in. Achievable with rainbow processing, but that seems a > bit of a faff... > > Andrew > > On 22 Apr 2012, at 21:34, Tommo H wrote: > >> Based on the Spectrum version, you could probably do it in Mode 1 or >> 2, just using the attributes? >> >> On 22 Apr 2012, at 13:32, Andrew Collier wrote: >> >>> so this is what people do on the internet these days, is it? >>> Actually it does remind me a bit of the kind of stuff that ended up >>> on early issues of Fred... >>> >>> You'd need to draw the stars manually, but that should be achievable. >>> >>> Andrew >>> >>> >>> On 22 Apr 2012, at 19:45, James R Curry wrote: >>> >>>> There are few enough frames that it could easily be done with screen >>>> swapping with a sampled version of the music playing. >>>> >>>> -- >>>> James R Curry >>>> >>>> >>>> On Apr 22, 2012, at 1:39 PM, "Aleš Keprt" wrote: >>>> >>>>> Do we have Nyan Cat on Sam Coupe? Somebody should make a conversion. >>>>> >>>>> >>>>> original version, Atari 800, ZX Spectrum, Commodore C16, Atari 2600: >>>>> http://www.youtube.com/watch?v=oQ5v9Qo6XzA >>>>> Amstrad CPC version: http://www.youtube.com/watch?v=dfD3WxgaiXo >>>>> BBC Micro version: http://www.youtube.com/watch?v=HBVQdx3dJ1c >>>>> >>>>> If you don't have time to watch it all, here is a "short" 100h summary: > >>>>> http://www.youtube.com/watch?v=AA5DsLzSVrk >>>>> >>>>> Sam Coupe version: ??? >>>>> >>>>> - >>>>> Mgr. Aleš Keprt, Ph.D. >>>>> private: a...@keprt.cz, www.keprt.cz >>>>> office: Moravian College / Moravská vysoká škola Olomouc, >>>>> ales.ke...@mvso.cz >>> > > > - > Mgr. Aleš Keprt, Ph.D. > private: a...@keprt.cz, www.keprt.cz > office: Moravian College / Moravská vysoká škola Olomouc, ales.ke...@mvso.cz > > > - > Mgr. Aleš Keprt, Ph.D. > private: a...@keprt.cz, www.keprt.cz > office: Moravian College / Moravská vysoká škola Olomouc, ales.ke...@mvso.cz > >
Re: Nyan Cat
Based on the Spectrum version, you could probably do it in Mode 1 or 2, just using the attributes? On 22 Apr 2012, at 13:32, Andrew Collier wrote: > so this is what people do on the internet these days, is it? > Actually it does remind me a bit of the kind of stuff that ended up on early > issues of Fred... > > You'd need to draw the stars manually, but that should be achievable. > > Andrew > > > On 22 Apr 2012, at 19:45, James R Curry wrote: > >> There are few enough frames that it could easily be done with screen >> swapping with a sampled version of the music playing. >> >> -- >> James R Curry >> >> >> On Apr 22, 2012, at 1:39 PM, "Aleš Keprt" wrote: >> >>> Do we have Nyan Cat on Sam Coupe? Somebody should make a conversion. >>> >>> >>> original version, Atari 800, ZX Spectrum, Commodore C16, Atari 2600: >>> http://www.youtube.com/watch?v=oQ5v9Qo6XzA >>> Amstrad CPC version: http://www.youtube.com/watch?v=dfD3WxgaiXo >>> BBC Micro version: http://www.youtube.com/watch?v=HBVQdx3dJ1c >>> >>> If you don't have time to watch it all, here is a "short" 100h summary: >>> http://www.youtube.com/watch?v=AA5DsLzSVrk >>> >>> Sam Coupe version: ??? >>> >>> - >>> Mgr. Aleš Keprt, Ph.D. >>> private: a...@keprt.cz, www.keprt.cz >>> office: Moravian College / Moravská vysoká škola Olomouc, ales.ke...@mvso.cz >
Re: SimCoupi
Having managed to get hold of a Raspberry Pi differentiates you from 99% of the world; using Google+ differentiates you from 99.9%. Looking good though! Versus running it on a normal computer, do we get genuine 50Hz output? On 16 Apr 2012, at 08:04, Simon Owen wrote: > On 16 Apr 2012, at 15:48, Wayne Weedon wrote: >> I just get a 403 error following that link.. Do you have some .htaccess >> rule in there somewhere? > > Oops! In case of caching, try this instead: http://simonowen.com/simcoupi > > I renamed the album title and that must have changed the link somehow. A > missing slash in the .htaccess also broke the shamview link a few days ago, > so I've not been doing too well overall. > > Si >
Re: ZX Spectrum 'relaunch'
If I dare bore by half mentioning it again, I've written a ZX80/81 emulator that's accurate at the bus level (to the nearest half a cycle, anyway). In theory you could attach real hardware to that and it wouldn't know the difference. It's a heavy-handed approach versus something like an FPGA that extends the natural signals but that sort of approach could be a route to a commodity Sam-in-a-box that accepts almost all original hardware add-ons. Anyone got any idea about how difficult it would be actually to engineer the break-out ports? I guess you'd just need to be able to get and set the signal at each pin, at least double the rate of the fastest exposed clock signal. On 13 Apr 2012, at 05:50, Stefan Drissen wrote: > It may have been the result of running the Speccy emulator Fuse on the Pi at > the 30th birthday event of the BBC micro > (http://connecteddigitalworld.com/2012/03/26/a-slice-of-raspberry-pi-at-beeb > 30/). > > "We'll have no more of that then, go find yourself another project to do..." > ;-) > > -Original Message- > From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On > Behalf Of war...@wdlee.co.uk > Sent: vrijdag 13 april 2012 14:24 > To: sam-users@nvg.ntnu.no > Subject: Re: ZX Spectrum 'relaunch' > > ahh, now if Simcoupe works on the Raspberry Pi... :-D sure, there's nothing > like using the real thing, but I'd definitely have to build myself a > mini-SAM emulator, even if only for portability! Hmmm... > visions of a SAMtop spring to mind... > > I keep checking those sites for the Pi, but to be honest, I'm starting to > wonder what's happening with it. It had great momentum, and then just when > things are about ready, the two companies who were to exclusively release it > stop things in their tracks? > > It's obviously just the conspiracy theorist in me, but I remember all the > mentions about how the Pi would be used in oppressed countries for cheap and > secure communications... And I can't help wondering if some 'behind the > scenes' pressure has been used to slow things down and make it lose the > momentum it had. Or even just from technology companies at the prospect of > something so cheap but effective that could potentially damage the market > for expensive lower end gadgets. > (I mean, picture how many extremely cheap home-made netbook kits could be > released on ebay, with Pi's at their core and cheap keyboards and > screens) O maybe I've just read too many conspiracy theory books lol! > > SimCoupe running on a 'sortof ZX Spectrum' would just be... well, surreal... > ;- > > Warren > > Quoting Simon Owen : > >> Bonus points if you then run SimCoupe on it, to see if it still feels > wrong! >> >> I created a quick SimCoupe binary for the Raspberry Pi back in Feb, >> which I've tested in the development VM under QEMU. Still waiting for >> real hardware to see how well it runs though. I was kinda hoping I >> pre-registered early enough with RS, but I've not received one of the >> magic vouchers yet. I'll have to see if my Farnell order works out... >> >> Si >> >> >> On 13 Apr 2012, at 12:43, war...@wdlee.co.uk wrote: >> >>> There's something very cool about seeing a spectrum do all that (Even >>> if it's really just the case with something else running emulation). >>> I hadn't thought too much about the keyboard, but I suppose that >>> would really be the major difficulty: Getting something that plays >>> exactly like the original but maps to PC keyboard types for the >>> emulator. >>> >>> In theory, you could get a cheap 2nd hand spectrum (even non-working >>> one), a rasberry pi or beagle, and it would come to, what, somewhere >>> under £50? And assuming some relatively easy method of fixing up the >>> keyboard, you could fairly easily create your own. >>> :-) (say's the person who knows nothing about it lol!) It'd be cool >>> if someone created a general guide for doing it cheaply that way, >>> with the appropriate software for the Pi or Beagle, and some extra >>> gadget for the keyboard hookup. Then it would make a nice pack to >>> sell to enthusiasts with little-to-no knowledge of hardware and >>> electronics. >>> >>> Graeme, it would be very cool to see where you get with that! >>> Definitely something you should get working. ;-) >>> >>> Warren >>> >>> Quoting Andrew Gillen : >>> Hi Warren This idea reminds me of the ZX Spectrum that was modded to run linux. Check out http://www.retrothing.com/2009/04/modding-a-sinclair-zx-spectrum-to- run-linux.html http://www.retrothing.com/2009/04/modding-a-sinclair-zx-spectrum-to- run-linux.html and http://www.youtube.com/watch?v=a0qh7dvaH98 That Beagleboard solution isn't a cheap one, and it requires a fair bit of hackery to get the keyboard sorted, but it looks like a fantastic result. I'd like to try the PI out in a similar capacity, but I lack the degree of expertise in electrical hackery unfortunately to see
Re: Essential Sam Goodies
I know it's going to make me sound tediously predictable but I still think David Gommeren's Tetris is the quintessential Sam game, despite not even being that fantastic a Tetris (compared to my personal favourite, the Spectrum's Tetris 2, anyway). Beyond that, get WaterWorks. It's another puzzle game, technically, but it's a lot more interesting than most. You sort of have to move pipes around to direct water, but unlike Pipemania or whatever the water flows freely into the game environment and collects on the floor if you let it. http://www.worldofsam.org/node/75 http://www.worldofsam.org/node/50 On 12 Apr 2012, at 07:02, "war...@wdlee.co.uk" wrote: > Welcome, Graeme!! :-D > > It's always good to see a new SAM user. I hope you get lots of fun from it, > as there is a ton of stuff to get into. Others have listed a lot of the major > software and so forth that you can get, but I'd really advise getting the > Trinity interface from Colin at samcoupe.com - It's a fantastic bit of > hardware and makes life much easier with the SD storage. Not to mention with > the online stuff coming, it's going to be enormous fun! ;-) (I even built my > own custom case for mine a while back - > https://twitter.com/#!/duncansguide/media/slideshow?url=http%3A%2F%2Ftwitpic.com%2F3e3ye6) > > Also, if you feel like other hardware, I'd advise Colin's Quazar Surround > sound module as well. It's great stuff! Get as many back-issues of SAM > Revival off him as well, as he's managed to publish a lot of excellent items > on the accompanying discs (*cough* issue 10 especially *cough*). > > You should also get a mouse adaptor from Colin, if you haven't got one with > the SAM. > > Games I would advise, Stratosphere (great addictive and action-packed > wireframe 3D game), Lemmings, Prince of Persia, Defenders of the Earth (Used > to get some flack, but it's fast with great graphics and lots of simple > shooter fun), Exodus, and others... There are plenty of great ones that > others have already listed, so I won't mention them all. Those are some of my > favourites. > > Software, I would say definitely get SAM Paint and Games Master. SAM Paint is > truly superb if you want to get into pixel graphics, and Games Master is > excellent for getting into making your own fun games. If you've done any > programming in the past, it's nice and easy to dive in and get a few fun > things going on without having to program basic or machine code. > > Also, download as many of the old FRED disc magazines as you can, since they > were packed with a wide selection of great demos and free games (*cough* > especially issue 58 and issue 75 *cough*). ;-) > > -> Geoff, you shouldn't give up on the SAM. :-) It's just that for a number > of people in the SAM community Jowett has gone FAR beyond mere Spam, and he's > marred a lot of the fun atmosphere, so it causes temperatures to run high. > Heck, he's even posted several irrelevant and unintelligible ramblings on my > blog, simply because I once mentioned the SAM in a couple of postings... and > I've had the LEAST trouble with him. ;-) If you can put up with deleting > Jowett's emails, do the same with the usergroup ones complaining about him, > and stay on the list. ;-) if you leave it because of the complaints about > him, you've still effectively let him ruin your fun of the SAM, which would > be a real shame. > > Warren > > Quoting Adrian Brown : > >> Welcome >> >> Head over to www.samcoupe.com as well. Colin Piggot has some bits and >> bobs to look at, when work doesn't get in the way ill hopefully >> completely finish the tcp/ip stack for the trinity interface. You can >> now use flash cards instead of floppy disks which is nice ;) >> >> As to games I know most people didn't but I liked sphera. It was fun :D >> >> Adrian >> >> -Original Message- >> From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] >> On Behalf Of toberm...@cookingcircle.co.uk >> Sent: 12 April 2012 12:31 >> To: sam-users@nvg.ntnu.no >> Subject: Re: Essential Sam Goodies >> >> Welcome Graeme! The Sam's as good 21 years later as it was Christmas >> 1990. We're generally cheerful too btw. >> >> Your best bet to find the best goodies is to visit World of Sam and have >> a damn good root around! Simcoupe itself is bundled with what I would >> call the best stuff, but you'll need a few things to port the PC images >> back to real floppies, namely SAMdisk (by Si Owen) and a PC with an >> INTERNAL 3.5 floppy drive (external won't do). >> >> Also have a good look round Andrew Collier's Intensity site because >> there's loads of great bits locked away. >> >> As for other stuff to get, I'd advise the Atom HDD, Stratosphere, >> Defender, Momentum, Lemmings, Protracker, E-tracker, SAMpaint, GI-mon, >> Comet, Pyz80, some kind of SAMdac or EDDAc, SAM mouse, and every >> diskzine you can get your hands on! There's just LOADS of great stuff >> available. >> >> What did I miss? >> Howard (
Re: Junk mail
I received five emails this morning, at least two of them to the same long list of people as those that started this conversation. For the record, I've never considered him to be a troll because he doesn't seem deliberately to be trying to annoy anyone, and his messages aren't deliberately provocative so much as just a little confusing. On 6 Apr 2012, at 10:38, Wayne Weedon wrote: > On 06/04/2012 16:14, Frode Tennebø wrote: >> On 6 April 2012 14:10, Roger Jowett wrote: >> >> [snipp] >> >> Sorry about that, folks. I shall try to be more vigilant. I have yet >> again forcibly unsubscribed him and will do so until I find a more >> permanent solution. >> >> -Frode >> > did he reply with a tirade of insults? Didn't see it so obviously my > filter worked!
Re: SAM HAM viewer
Coincidentally I've just recently written a ZX81 emulator for the PC. The way it uses refresh cycles to create a display counter is very clever indeed and definitely what I found most interesting. I didn't end up doing much prying into the software side of things since it was a PC-side thing, but I guess a lightweight handler was necessitated by the way the slow mode timer was added to the ZX80 hardware? Have you considered giving DOSBox a go for TASM? It interacts fully with the native filing system so you just end up with a cmd.exe alternative that runs a different set of software. On 2 Apr 2012, at 16:32, "Aleš Keprt" wrote: > Actually there is a commented source code on Simon's web. The viewer is > quite straighforward, all the colour magic lies in the converter. ;-) > I am now planning to create a zx81 emulator, and that computer is quite > interesting in that it doesn't push all registers to stack on interrupt. It > means that some registers can't be generally used when interrupt is enabled, > but the benefit is that the interrupt handelr routine is faster to start. > This zx81-way it would probably be possible to change more colours per > scanline. > > That brings me to the question if there exist 64bit TASM compiler. I always > used TASM with Z80 mactors to compile my programs, but now I can't run TASM > because my version is apparently a 16bit exe from MS-DOS. I would probably > need to find at least some 32bit edition, if that's possible. (I don't have > any experience with Python and I am not generally happy to install Python in > order to run Z80 crossassembler once in a while.) > A. > > -Původní zpráva- > From: Thomas Harte > Sent: Tuesday, April 03, 2012 12:58 AM > To: sam-users@nvg.ntnu.no > Subject: Re: SAM HAM viewer > > I've seen something similar on the Atari Lynx, which also has a 4 bit > frame buffer, the only difference being that I think that used a tight > loop of something like (i) load next palette index, next colour and > next delay length; (ii) push colour to palette index; (iii) perform a > busy loop of the desired length; (iv) repeat. The loop was > synchronised once with vertical retrace and timings were such that a > degenerate case was to change the entire palette once after every scan > line but you could instead, say, change a single palette index several > times over the course of a single scan line, or anything in between. > > A better adaption for the Sam might be to allow palette and mode > changes, and for simplicity to add a delay length that just means to > wait until the next vertical retrace? If you have portions of the > image with only four colours (especially once the colour aliasing > forced by the 128-colour palette is accounted for) then switching to > mode 3 for a portion of a line could be the smarter thing to do, and > would presumably cost basically nothing to implement? > > In terms of image conversion, I guess a heuristic would be the thing. > It feels like, even at Sam size, an exhaustive search could take > forever. > > Of course, I didn't disassemble Simon's fantastic work so it's > possible he's way ahead of me on this one. > > On 1 April 2012 18:05, Aleš Keprt wrote: >> Oh yes, this is nice. I saw similar things in the past, AFAIR this was >> published on some disk magazine back in 90's. But it will be hard to find >> it >> now. >> >> So how many colours are possible per line in this format? Or what is >> possible in this picture format? >> >> Also, I think that the converter could possibly de-noise the picture >> before >> or after the conversion. Or something like that. Because there are too >> many >> dots visible in places where there should be no dots. This is good in high >> resolution graphics like when printing on printer in 600 DPI, but doesn't >> look too well on Sam. Especially in emulator with crisp LCD display. ;-) I >> think the whole de-noising process is extremely important when converting >> to >> low resolution and low bitdepth. And each single picture needs a different >> values for the algorithm, so maybe there should be some kind of WYSIWYG >> editor or something where users could change some settings and see the >> result immediately in order to find the best settings for each file. ;-) >> Maybe a genetic algorithm could help to find at least some local optimum
Re: ASCD 0.98 WIP 2 released
I was working on taking a full-frame RGB signal in, separating into YUV, applying a low pass filter (because, e.g. the colour subcarrier is only 4.43361875Mhz, giving PAL a lower horizontal colour resolution than a Sam, though the luminance frequency is much higher) and recombining. Pretty trivial to do in general and it gives you a lot of the PAL look -- doing it on the GPU is smart because in an emulator you're almost certainly not otherwise using it. I just used a quick Kaiser-Bessel type filter, which is really not the sort of thing the GPU is good at, but it still worked quite well. I was then looking at shadow mask emulation, but got distracted. Since a lot of that is very basic digital signal processing stuff, I was suggesting you'd be well placed to look into it because you seem to have a background in audio. On 28 Mar 2012, at 11:27, "Aleš Keprt" wrote: Tommo, I'm afraid I don't understand what are you talking about in your second paragraph. AD Codecs: I tried a few codecs from Windows, MJPEG which I used in the past, and then I searched for some lossless codecs. The best one is SCLS, the second best is MSUD - they are both from Moscow State University (MSU). You can download them for free from their website. SCLS is superior in all aspects - it is very fast, it has best compression ratio (by far), it doesn't need any configuration settings. Microsoft video 1 (a standard very old codec which is present in all Windows) is also able to compress losslessly the ZX Spectrum video, but its compression ratio is much worse compared to MSU codecs. Radius Cinepak (another standard old codec from Windows) has very bad picture quality and is slow. I also tried MJPEG codecs, but the results weren't good - it is necessary to use the highest mjpeg quality settings, files are quite large and the compression process is slow. I didn't try XVID or other MPEG4 codecs because I am sure it would be bad as well. The SCLS codec is fast and produces the smallest files, so it is the #1 choice. Yesterday I recorded 12 minutes of North Star gameplay. SCLS video is 3.75 MB, MSUD is 36.9 MB, while other codecs produce much larger files. So it is approximately 19 MB per hour, that's amazing. :-) These values are for full resolution with border and 50 frames per second! It is much worse with audio. In the fact there is no single good codec available. I read article on Wikipedia on this topic - unfortunately ACM (audio compression manager in Windows) has troubles with variable bitrate (it doesn't support it at all to be more precise). MP3 is pain, OGG is yet bigger pain, similarly AC3 or AAC are pain as well. In addition all these codecs are quite unsuitable for computer music. My final choice is Microsoft ADPCM, its bitrate is 384 kbps (for 48kHz stereo), i.e. 172 MB per hour, and I think the audio quality is good. And it is installed in each Windows and also supported by MPlayer on all other platforms. It would be better to create a new custom audio codec, but I rather let the files to be big than to use nonstandard codec for audio. Standard AVI files have got file size limit at 2.0 GB. Normally I can record only 5.5 minutes of uncompressed RGB video to those 2 GB at 25 frames per second. When I use SCLS, I can go up to 50 frames per second, and still I am limited only by the size of audio track. More than 10 hours of uninterrupted recording will fit into 2 GB. :-) Best regards, Aley Keprt *From:* Tommo H *Sent:* Wednesday, March 28, 2012 7:21 AM *To:* sam-users@nvg.ntnu.no *Subject:* Re: ASCD 0.98 WIP 2 released Which codec is that, if I may ask? Something much more fun than dealing with complicated interfaces in a platform-neutral manner that I recently experimented with was a GPU-driven pipeline for PAL simulation. If I recall, you did a lot of work on SAA emulation back in the day, which must give rise to some broadly similar DSP sort of topics so have you any plans there? On 26 Mar 2012, at 10:41, "Aleš Keprt" wrote: I think what you suggest is possible, I had these thoughts too. But currently I am quite happy with simple quicksave feature, and there is also history of quicksaves stored on disk, so you can eventually revert to any of older saves. What you suggest would move the emulator even further to something like a movie cutting studio. ;-) But it would also bring more complicated menu/GUI to control these features. I personally prefer the quick one, just because it's really "quick". Currently I have implemented AVI recording. Interestingly, I found a nice lossless video codec which can record several minutes of video into just 1.0 MB AVI file. :-) Audio track is then much larger than video track, which is quite unusual. ;-) Aley *From:* Tommo H *Sent:* Friday, March 23, 2012 1:31 AM *To:* sam-users@nvg.ntnu.no *Subject:* Re: ASCD 0.98 WIP 2 released If I dare make a suggestion; what might be nice
Re: ASCD 0.98 WIP 2 released
Which codec is that, if I may ask? Something much more fun than dealing with complicated interfaces in a platform-neutral manner that I recently experimented with was a GPU-driven pipeline for PAL simulation. If I recall, you did a lot of work on SAA emulation back in the day, which must give rise to some broadly similar DSP sort of topics so have you any plans there? On 26 Mar 2012, at 10:41, "Aleš Keprt" wrote: I think what you suggest is possible, I had these thoughts too. But currently I am quite happy with simple quicksave feature, and there is also history of quicksaves stored on disk, so you can eventually revert to any of older saves. What you suggest would move the emulator even further to something like a movie cutting studio. ;-) But it would also bring more complicated menu/GUI to control these features. I personally prefer the quick one, just because it's really "quick". Currently I have implemented AVI recording. Interestingly, I found a nice lossless video codec which can record several minutes of video into just 1.0 MB AVI file. :-) Audio track is then much larger than video track, which is quite unusual. ;-) Aley *From:* Tommo H *Sent:* Friday, March 23, 2012 1:31 AM *To:* sam-users@nvg.ntnu.no *Subject:* Re: ASCD 0.98 WIP 2 released If I dare make a suggestion; what might be nice now that memory is so large would be to ditch fast loads and saves (or at least significantly demote them) in favour of a simple jog dial. So I'd be able to rewind with, say, frame accuracy for the last five minutes, second accuracy for the five minutes before that, etc. Obviously you'd want to approach the problem similarly to compressed video, with key frames and the subsequent few stored as delta differences. If you just densely stored the entire state, and pretending it were just the RAM for ease of calculation, 50fps for five minutes is 15,000 frames, for a footprint of 15,000 times 512kb or about 7.3 gigabytes. A key frame each second for five minutes is already only 150mb and the delta changes would likely be light. If you reduced it to just storing input as deltas (whether things the machine inherently reads or things the emulator supplies like disk changes) then they'd cost almost nothing at all either to compute or to store. Good idea? Bad idea? On 22 Mar 2012, at 16:12, "Aleš Keprt" wrote: Thank you very much. It is a bug in emulator - apparently the end of file mark is not saved correctly. (One zero byte is missing at the end of the file.) And yes, now we are able to finish some games quite easily, for example I finished Exolon yesterday. Best regards, Aley Keprt *From:* Andrew Gillen *Sent:* Thursday, March 22, 2012 11:29 PM *To:* sam-users@nvg.ntnu.no *Subject:* Re: ASCD 0.98 WIP 2 released Hi Aleš Great work on this emulator. I tried it this evening and it plays a mean game of Dave Invaders and even the demo of Dave Infuriators Quick load and save seems to work great but with one small bug (that I'm sure you know about already but I thought I'd mention anyway) when I Quickload from the Emulation menu it says it fails to load, but actually loads fine. The F9 key doesn't offer up the same error. Anyway, I might actually be able to complete my own game now without resorting to a cheat mode Looking forward to further development. All the best Andrew *From:* Aleš Keprt *Sent:* Thursday, March 22, 2012 2:26 AM *To:* sam-users@nvg.ntnu.no *Subject:* ASCD 0.98 WIP 2 released Hi Sam Users! I just released the new version of my emulator ASCD 0.98 WIP 2. It's still "work-in-progress", but many planned things are already implemented. You can download it from my web site www.keprt.cz - click Download, then see at the bottom of that page. Snapshots are now enabled for use, they are saved to the new file format with extension SCS (aka. Sam Coupe Snapshot). The file format is self-described in the source code (see file SamSnap.cpp). The new fileformat covers also ZX Spectrum 48/128 snapshots, as it is the fileformat used for internal Quicksave/Quickload feature. You can also simultaneously write action replay recording file and use quicksave/quickload. My plan is to add AVI video recording to let people record "walkthrough" videos in games. Until this is implemented, ASCD 0.98 won't reach final state. What's new: - 0.98 WIP 2 - march 2012 == * Sam Coupé Snapshots are now public; next goal is to implement AVI video file writer * The snapshot code is still in development, now supported also for ZX Spectrum modes * QuickSave/QuickLoad feature now uses new snapshot format in all modes, including air recording * New file format for OpenAir recordings - files are now a lot smaller * Sam: Added printer support (wasn't implemented in Windows version yet) - saves to printout.txt * Sam: Improved floppy disk drive emulation, SAMDICE doesn'
Re: ASCD 0.98 WIP 2 released
If I dare make a suggestion; what might be nice now that memory is so large would be to ditch fast loads and saves (or at least significantly demote them) in favour of a simple jog dial. So I'd be able to rewind with, say, frame accuracy for the last five minutes, second accuracy for the five minutes before that, etc. Obviously you'd want to approach the problem similarly to compressed video, with key frames and the subsequent few stored as delta differences. If you just densely stored the entire state, and pretending it were just the RAM for ease of calculation, 50fps for five minutes is 15,000 frames, for a footprint of 15,000 times 512kb or about 7.3 gigabytes. A key frame each second for five minutes is already only 150mb and the delta changes would likely be light. If you reduced it to just storing input as deltas (whether things the machine inherently reads or things the emulator supplies like disk changes) then they'd cost almost nothing at all either to compute or to store. Good idea? Bad idea? On 22 Mar 2012, at 16:12, "Aleš Keprt" wrote: Thank you very much. It is a bug in emulator - apparently the end of file mark is not saved correctly. (One zero byte is missing at the end of the file.) And yes, now we are able to finish some games quite easily, for example I finished Exolon yesterday. Best regards, Aley Keprt *From:* Andrew Gillen *Sent:* Thursday, March 22, 2012 11:29 PM *To:* sam-users@nvg.ntnu.no *Subject:* Re: ASCD 0.98 WIP 2 released Hi Aleš Great work on this emulator. I tried it this evening and it plays a mean game of Dave Invaders and even the demo of Dave Infuriators Quick load and save seems to work great but with one small bug (that I'm sure you know about already but I thought I'd mention anyway) when I Quickload from the Emulation menu it says it fails to load, but actually loads fine. The F9 key doesn't offer up the same error. Anyway, I might actually be able to complete my own game now without resorting to a cheat mode Looking forward to further development. All the best Andrew *From:* Aleš Keprt *Sent:* Thursday, March 22, 2012 2:26 AM *To:* sam-users@nvg.ntnu.no *Subject:* ASCD 0.98 WIP 2 released Hi Sam Users! I just released the new version of my emulator ASCD 0.98 WIP 2. It's still "work-in-progress", but many planned things are already implemented. You can download it from my web site www.keprt.cz - click Download, then see at the bottom of that page. Snapshots are now enabled for use, they are saved to the new file format with extension SCS (aka. Sam Coupe Snapshot). The file format is self-described in the source code (see file SamSnap.cpp). The new fileformat covers also ZX Spectrum 48/128 snapshots, as it is the fileformat used for internal Quicksave/Quickload feature. You can also simultaneously write action replay recording file and use quicksave/quickload. My plan is to add AVI video recording to let people record "walkthrough" videos in games. Until this is implemented, ASCD 0.98 won't reach final state. What's new: - 0.98 WIP 2 - march 2012 == * Sam Coupé Snapshots are now public; next goal is to implement AVI video file writer * The snapshot code is still in development, now supported also for ZX Spectrum modes * QuickSave/QuickLoad feature now uses new snapshot format in all modes, including air recording * New file format for OpenAir recordings - files are now a lot smaller * Sam: Added printer support (wasn't implemented in Windows version yet) - saves to printout.txt * Sam: Improved floppy disk drive emulation, SAMDICE doesn't crash anymore, although it still doesn't work * Sam: Improved mouse emulation code * ZXS: Added support for 3x8bit DAC audio based on IC 8255 (ports 31,63,95,127 - MQM5 works :-)) * ZXS: Added support for Fullerbox AY audio (it's always turned on in ZXS 48/128k mode) * ZXS: Added ZX Printer support - it saves the prints to zxprint.bmp file * Z80: Fixed ADC HL,rr incorrectly setting N flag * Z80: Added support for saving .z80 snapshot files (uncompressed 48KB only) * Mouse was too fast, so it is set 2 times slower than before * Changed contents of a disk images are now saved with a temp filename and then renamed back only if no error occurs 0.98 WIP 1 - march 2012 == * First public Win32 version - supports Windows 2000 and later, DirectX 6 (2D) and Direct3D 9 (3D) * MS-DOS version is now officially dropped * Updated to Visual C++ 2008 and Zlib 1.2.6 * Fixed many bugs in the emulation core * Fixed Windows related bugs (especially in GUI) * Added support for saving .sna snaps (both 48k and 128k) * Added many items to Windows menu, but this is still quite incomplete * Fixed wrong flash speed (it flashed every 25 frames, now it flashes every 16 frames) Best regards, Aley Keprt - Mgr. Aleš Keprt, Ph.D. private: a...@keprt.cz, www.keprt.cz office: Moravian College / Moravská vysoká škola Olomouc, ales.ke...@mvso.cz --
Re: Contention and JR instruction timing.
On 26 Apr 2011, at 14:38, Geoff Winkless wrote: 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_. 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. Doing it twice in two frames with time to do something else on actual hardware doesn't sound so impossible. > 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. And the official DMA chip is quite a bit more complicated than the de minimis functionality I was suggesting. I also thought the Sam didn't drop to £200 until after the first Christmas, but I'm probably confusing myself with when the disk drive started coming for free - meaning they'd found £70 (retail, admittedly, so a lot less than that really) of savings somewhere. Chuck it on the same board as the RAM expansion if you have an absolute minimum price of entry you need to hit. 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) No, 80% (and I used one of the 16bit pushes in an unrolled loop with a suitably calculated entry point, i.e. no inner-loop conditional). So you (hypothetically) cut 40% of the total cost. Or, the other way around, you run two-thirds faster on the poly drawing, which is most of the total frame cost, based on experience from other systems. (figures based on dim recollections from Sim Coupe-aided profiling, more than a year and a half ago, probably quite significantly rounded at this point). In terms of 8bit state-of-the-art for 1989 if development budget were no issue, the Atari Lynx has to be the standard bearer. 4Mhz 6502, scaling blitter that can do lines in a single call, arbitrary filled triangles in two, a proper grown-up 4bit frame buffer, better-than-AY (but nowhere near the Sam) sound chip, maths coprocessor, and all quite a bit less than £200 with a built-in LCD screen. Of course, backwards compatibility wasn't a concern and it probably cost and lost a lot more money than the Sam did. So, ummm, instructive on production costs, unlikely to be on design costs.
Re: Contention and JR instruction timing.
On 26 Apr 2011, at 13:47, Geoff Winkless wrote: On 26 April 2011 13:15, Thomas Harte wrote: 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. The 25fps is based on a hypothetical chip having the same access as the CPU does currently. 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, and the z80 has a halt line so the mechanics of pausing it aren't all that complicated. 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. 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. As stated, this is an alternative idea, that occurs in the situation where the screen address can't be made editable for some other reason. There's no programmatic advantage to it, but it shifts the burden to the hardware on the other side of the analogue conversion, giving different options for where you can fit it into the silicon budget. 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 :) Horizontal or vertical, and it (or any of the other options discussed in this thread) would have made the vast majority of early-1990s games implementable on the Sam, making it a better market proposition and hence likely increasing sales by some percentage. Other market factors would have been the same, but I'm sure MGT would have found even, e.g. a 20% increase in sales to be useful. Plus, you know, we'd all have been able to play Strider. For definite.
Re: screen modes
>From memory, it all starts at 16384 (directly after the Spectrum ROM); it's all the pixels first, then all the attributes (so, attributes start at 16384+6144). Attributes and individual scan lines are linear, but the scan lines are stored in a peculiar order - it's the first, then the ninth, then the seventeenth, etc, until you get to the 56th, then you hop back up to do the 2nd, the 10th, etc. The 64th comes after the 63rd, then the relative offsets repeat. So, putting it another way: cut the screen into three portions, each of 8 character rows. Each of those is stored so that it's all the first lines of the character rows, then all the second, etc. When you've filled in all the pixels, move to the next set of character lines. Which, thinking extemporaneously, I guess means that the lowest three bits and the three bits next to them are exchanged. Watch a Spectrum game loading for a live demonstration of byte order. The lines will fill in, in the order I've tried poorly to describe three times, then finally the colours. The data is just being pushed into memory in linear order. On 24 Apr 2011, at 20:44, Andrew Park wrote: I can’t remember for the life of me how mode 1 is mapped out where is the start address of the screen and where is the attribute data stored Andy
