Re: Some SAM hardware for sale
Without being able to answer on the Timex or the extent to which the RAM upgrade would benefit 128k emulation, was Mercenary the one where they appeared to be drawing on only every other scanline? It's possible I've merged it with Battle Command (filled polys, draws only every other line) in my memory. I'm not completely sure on the external RAM modules, but my understanding is that they're not contended at all, which would be a substantial speed improvement for the 3d calculation parts of this sort of code and some improvement to the pixel throwing. Technically my code can do display without hidden line removal, it's just a consequence of the algorithm rather than a deliberately designed feature. It's the Elite method, each line is considered a potential edge and connected to two faces. If either face is visible then the line is drawn. The links are pointers, so you'd set both pointers to a face that isn't connected as part of the model (so the code won't recalculate whether it is visible when you draw) and has the visibility flag set. On Thu, May 27, 2010 at 9:30 AM, Roger Jowett wrote: > did you see mercenary - the 3d stuff above ground was made up of dots > adn wasnt solid line removed - like starion just vectors without > hidden line removal(vu3d terminology! - mind you the shading took all > day on vu3d whereas 3d construciton kit managed to do it in 3-4 frames > possibly less with the dma from the mb-02+ - shame no one bothered > with the fdd3k had a 4mhz z80? but connected via serial interface - > assume it was faster than the interface 1 9600baud? dunno what the > sams comms interface was 19200?baud) > velesoft reckon the external 4mb has different paging to sam - can > page 16kb into last two ram pages CD of hmpr? there wasnt much info on > this in the technical manual but velesoft reckon it might help with > 128 conversion - i was thinking the sams extra ram could be filled > with every possible combination of pages that the 128 could have and > then the port out to change the ram page could be altered to the > single byte valu to include the two correct pages - this would mean > duplicating ram pages in the sams ram internal (external - might not > need to bother) > > > forgot about that - was that the case for the timex extra attribute > screen mode? or the 512x192 mode of the timex? > do you know if it had paper and colour settings for hi rez? > > On 26 May 2010 15:01, Thomas Harte wrote: >> Mode 1 routines would very nearly work in Mode 2, the main difference >> being that Mode 2 has a linear pixel layout but Mode 1 replicates the >> order of the ZX Spectrum by switching some of the bits around. There's >> also a gap between the Mode 2 pixel data and the attribute data, >> whereas in Mode 1 the attribute data is immediately after the pixel >> data (and there's less of it too, per the attribute size differences). >> >> You know when you load a Spectrum game from tape, the title screen >> almost always loads as the first line, then the 8th, then the 16th, >> then eventually it jumps back up and adds in the 2nd, then the 9th, >> etc, it does that pattern once for each third of the screen and then >> finally the colours appear? That's because that's the order video >> memory is laid out in on a Spectrum. >> >> I've never seen an explanation as to why. But the individual scanlines >> are still linear, so it tends not to cause substantial difficulty and, >> conveniently, means it's usually easy to convert code from Mode 1 to 2 >> — often by removing a lookup table reference or a small chunk. >> >> On Wed, May 26, 2010 at 1:43 PM, Roger Jowett wrote: >>> does that mean that mode one reoutines might work in mode 2 then? >>> >>> On 25 May 2010 21:04, Thomas Harte wrote: >>>> 3d data isn't graphics mode dependant like 2d data, but also doesn't >>>> have any particular common layout so it's really difficult to pull >>>> from existing titles. That's in contrast to 2d data, since you pretty >>>> much always store that in the format it would need to be in video >>>> memory in order to appear on screen. >>>> >>>> I'm using a standard Bresenham drawer (ie, each pixel it asks itself >>>> 'should I continue straight or is this a stair step?') so in principle >>>> Mode 3 would cost more. I've never been able to decide whether a run >>>> length Bresenham drawer (which is one 8 bit divide, but then the >>>> decision is 'is this run n pixels or n+1' so you save a lot on the >>>> journey across — and this explicitly isn
Re: Some SAM hardware for sale
Removing hidden line removal would save the time calculating face visibility but then add to transformation and drawing costs. The code at present always does a calculation for every defined face, always considers a calculation for every defined line and performs calculations for vertices only if they are used as part of the model as it is visible for that draw operation. Vertices that are connected only to lines that aren't visible aren't transformed. If I were to rewrite it, I would adjust that so that, as a first measure, a calculation is performed for every defined face but lines that aren't connected to visible faces are never even considered. That's not a massive win in performance terms because all it does for lines at the minute is run through reading a couple of flags and proceeding or discarding based on the combination of those. However, if I were then able to add a broad phase to the face stuff* then it'd really start to pay off down the hierarchy. * as in, a prepatory step that interrogates some sort of hierarchical structure and hence discards large swathes of faces without doing a calculation for each. Usually it saves time even if it is able to reject, say, only 90% of invisible faces and then you have to do the face-by-face tests on each of the remaining potentially visible set. I've never been 100% on the best, or even a necessarily suitable hierarchical form. On Thu, May 27, 2010 at 12:51 PM, Roger Jowett wrote: > so no hidden line removal speeds things up a bit... > http://www.worldofspectrum.org/infoseekid.cgi?id=0003126 > theres a screen shot only the roads were solid line the objects seemed > to be dots and not hidden line either > think in th erooms things were all solid > can be seen better in this screen shot > > http://www.worldofspectrum.org/infoseek.cgi?regexp=^Mercenary%3a+The+Second+City$&pub=^Novagen+Software+Ltd$&loadpics=1 > > thought battle carrier command were pretty solid/shaded 3dnot vecotrs? > > On 27 May 2010 12:08, Thomas Harte wrote: >> Without being able to answer on the Timex or the extent to which the >> RAM upgrade would benefit 128k emulation, was Mercenary the one where >> they appeared to be drawing on only every other scanline? It's >> possible I've merged it with Battle Command (filled polys, draws only >> every other line) in my memory. >> >> I'm not completely sure on the external RAM modules, but my >> understanding is that they're not contended at all, which would be a >> substantial speed improvement for the 3d calculation parts of this >> sort of code and some improvement to the pixel throwing. >> >> Technically my code can do display without hidden line removal, it's >> just a consequence of the algorithm rather than a deliberately >> designed feature. It's the Elite method, each line is considered a >> potential edge and connected to two faces. If either face is visible >> then the line is drawn. The links are pointers, so you'd set both >> pointers to a face that isn't connected as part of the model (so the >> code won't recalculate whether it is visible when you draw) and has >> the visibility flag set. >> >> On Thu, May 27, 2010 at 9:30 AM, Roger Jowett wrote: >>> did you see mercenary - the 3d stuff above ground was made up of dots >>> adn wasnt solid line removed - like starion just vectors without >>> hidden line removal(vu3d terminology! - mind you the shading took all >>> day on vu3d whereas 3d construciton kit managed to do it in 3-4 frames >>> possibly less with the dma from the mb-02+ - shame no one bothered >>> with the fdd3k had a 4mhz z80? but connected via serial interface - >>> assume it was faster than the interface 1 9600baud? dunno what the >>> sams comms interface was 19200?baud) >>> velesoft reckon the external 4mb has different paging to sam - can >>> page 16kb into last two ram pages CD of hmpr? there wasnt much info on >>> this in the technical manual but velesoft reckon it might help with >>> 128 conversion - i was thinking the sams extra ram could be filled >>> with every possible combination of pages that the 128 could have and >>> then the port out to change the ram page could be altered to the >>> single byte valu to include the two correct pages - this would mean >>> duplicating ram pages in the sams ram internal (external - might not >>> need to bother) >>> >>> >>> forgot about that - was that the case for the timex extra attribute >>> screen mode? or the 512x192 mode of the timex? >>> do you know if it had paper and colour settings for hi rez? >>> >>&g
Re: Some SAM hardware for sale
My own routine. It's in the drawline.z80s file, and it should be safe to swap it out for any other function as long as it accepts the same input and leaves the same registers intact (I think just IX and IY, but go with whatever the comment in that file says rather than what I'm saying now). My understanding was that the way that they've generalised the pixel plotting step to support different drawing modes and to do viewport testing within the line routine means that the ROM routines would be slower than my RAM routines. My routines benefit from only ever doing one of two things: - drawing a solid, single pixel wide line that is definitely entirely on the screen (ie, no need to test per pixel) - erase an old line, being allowed also to blank out any other pixels the routine feels like (which in practice means that it calculates the correct (x, y) for each pixel then just zeroes that byte in video memory, actually blanking two pixels) The latter could probably be faster if you halved the notional x resolution in which you're drawing and blanked out four pixels rather than two (to deal with occasions when the rounded version pixels the byte one to the side of the one that the non-rounded routine would have picked). I haven't experimented there. On Thu, May 27, 2010 at 3:19 PM, Roger Jowett wrote: > how are lines drawn using rom routine or your own? > > On 27 May 2010 15:14, Thomas Harte wrote: >> Removing hidden line removal would save the time calculating face >> visibility but then add to transformation and drawing costs. >> >> The code at present always does a calculation for every defined face, >> always considers a calculation for every defined line and performs >> calculations for vertices only if they are used as part of the model >> as it is visible for that draw operation. Vertices that are connected >> only to lines that aren't visible aren't transformed. >> >> If I were to rewrite it, I would adjust that so that, as a first >> measure, a calculation is performed for every defined face but lines >> that aren't connected to visible faces are never even considered. >> That's not a massive win in performance terms because all it does for >> lines at the minute is run through reading a couple of flags and >> proceeding or discarding based on the combination of those. However, >> if I were then able to add a broad phase to the face stuff* then it'd >> really start to pay off down the hierarchy. >> >> * as in, a prepatory step that interrogates some sort of hierarchical >> structure and hence discards large swathes of faces without doing a >> calculation for each. Usually it saves time even if it is able to >> reject, say, only 90% of invisible faces and then you have to do the >> face-by-face tests on each of the remaining potentially visible set. >> I've never been 100% on the best, or even a necessarily suitable >> hierarchical form. >> >> On Thu, May 27, 2010 at 12:51 PM, Roger Jowett wrote: >>> so no hidden line removal speeds things up a bit... >>> http://www.worldofspectrum.org/infoseekid.cgi?id=0003126 >>> theres a screen shot only the roads were solid line the objects seemed >>> to be dots and not hidden line either >>> think in th erooms things were all solid >>> can be seen better in this screen shot >>> >>> http://www.worldofspectrum.org/infoseek.cgi?regexp=^Mercenary%3a+The+Second+City$&pub=^Novagen+Software+Ltd$&loadpics=1 >>> >>> thought battle carrier command were pretty solid/shaded 3dnot vecotrs? >>> >>> On 27 May 2010 12:08, Thomas Harte wrote: >>>> Without being able to answer on the Timex or the extent to which the >>>> RAM upgrade would benefit 128k emulation, was Mercenary the one where >>>> they appeared to be drawing on only every other scanline? It's >>>> possible I've merged it with Battle Command (filled polys, draws only >>>> every other line) in my memory. >>>> >>>> I'm not completely sure on the external RAM modules, but my >>>> understanding is that they're not contended at all, which would be a >>>> substantial speed improvement for the 3d calculation parts of this >>>> sort of code and some improvement to the pixel throwing. >>>> >>>> Technically my code can do display without hidden line removal, it's >>>> just a consequence of the algorithm rather than a deliberately >>>> designed feature. It's the Elite method, each line is considered a >>>> potential edge and connected to two faces. If either face is visible >&g
Re: Some SAM hardware for sale
I had one further thought on this overnight: if you expand the planes bounding a convex object out to infinity then you get a series of convex cells surrounding the object. Which cell you're in exactly determines which faces you can see and the natural way to figure out which convex cell a player is in is a BSP tree. So you could reduce the face visibility check from its current linear time to logarithmic time - 5 or 6 checks for the Cobra Mk 3 (the most complicated model I've tried) rather than 30 odd and always 3 rather than 6 for the cube (the simplest). It definitely helps to talk about this stuff... On Thursday, May 27, 2010, Thomas Harte wrote: > My own routine. It's in the drawline.z80s file, and it should be safe > to swap it out for any other function as long as it accepts the same > input and leaves the same registers intact (I think just IX and IY, > but go with whatever the comment in that file says rather than what > I'm saying now). > > My understanding was that the way that they've generalised the pixel > plotting step to support different drawing modes and to do viewport > testing within the line routine means that the ROM routines would be > slower than my RAM routines. My routines benefit from only ever doing > one of two things: > > - drawing a solid, single pixel wide line that is definitely entirely > on the screen (ie, no need to test per pixel) > - erase an old line, being allowed also to blank out any other pixels > the routine feels like (which in practice means that it calculates the > correct (x, y) for each pixel then just zeroes that byte in video > memory, actually blanking two pixels) > > The latter could probably be faster if you halved the notional x > resolution in which you're drawing and blanked out four pixels rather > than two (to deal with occasions when the rounded version pixels the > byte one to the side of the one that the non-rounded routine would > have picked). I haven't experimented there. > > On Thu, May 27, 2010 at 3:19 PM, Roger Jowett wrote: >> how are lines drawn using rom routine or your own? >> >> On 27 May 2010 15:14, Thomas Harte wrote: >>> Removing hidden line removal would save the time calculating face >>> visibility but then add to transformation and drawing costs. >>> >>> The code at present always does a calculation for every defined face, >>> always considers a calculation for every defined line and performs >>> calculations for vertices only if they are used as part of the model >>> as it is visible for that draw operation. Vertices that are connected >>> only to lines that aren't visible aren't transformed. >>> >>> If I were to rewrite it, I would adjust that so that, as a first >>> measure, a calculation is performed for every defined face but lines >>> that aren't connected to visible faces are never even considered. >>> That's not a massive win in performance terms because all it does for >>> lines at the minute is run through reading a couple of flags and >>> proceeding or discarding based on the combination of those. However, >>> if I were then able to add a broad phase to the face stuff* then it'd >>> really start to pay off down the hierarchy. >>> >>> * as in, a prepatory step that interrogates some sort of hierarchical >>> structure and hence discards large swathes of faces without doing a >>> calculation for each. Usually it saves time even if it is able to >>> reject, say, only 90% of invisible faces and then you have to do the >>> face-by-face tests on each of the remaining potentially visible set. >>> I've never been 100% on the best, or even a necessarily suitable >>> hierarchical form. >>> >>> On Thu, May 27, 2010 at 12:51 PM, Roger Jowett >>> wrote: >>>> so no hidden line removal speeds things up a bit... >>>> http://www.worldofspectrum.org/infoseekid.cgi?id=0003126 >>>> theres a screen shot only the roads were solid line the objects seemed >>>> to be dots and not hidden line either >>>> think in th erooms things were all solid >>>> can be seen better in this screen shot >>>> >>>> http://www.worldofspectrum.org/infoseek.cgi?regexp=^Mercenary%3a+The+Second+City$&pub=^Novagen+Software+Ltd$&loadpics=1 >>>> >>>> thought battle carrier command were pretty solid/shaded 3dnot vecotrs? >>>> >>>> On 27 May 2010 12:08, Thomas Harte wrote: >>>>> Without being able to answer on the Timex or the extent to which the >>>>> RAM upgrade would ben
Re: Some SAM hardware for sale
Actually, 3 or 4 for the cube, now I think about it. But you get the point. Always nicer when you realise that what you're doing exactly fits an extremely well-documented and well-known data structure and algorithm. On Fri, May 28, 2010 at 8:54 AM, Thomas Harte wrote: > I had one further thought on this overnight: if you expand the planes > bounding a convex object out to infinity then you get a series of > convex cells surrounding the object. Which cell you're in exactly > determines which faces you can see and the natural way to figure out > which convex cell a player is in is a BSP tree. So you could reduce > the face visibility check from its current linear time to logarithmic > time - 5 or 6 checks for the Cobra Mk 3 (the most complicated model > I've tried) rather than 30 odd and always 3 rather than 6 for the cube > (the simplest). > > It definitely helps to talk about this stuff... > > On Thursday, May 27, 2010, Thomas Harte wrote: >> My own routine. It's in the drawline.z80s file, and it should be safe >> to swap it out for any other function as long as it accepts the same >> input and leaves the same registers intact (I think just IX and IY, >> but go with whatever the comment in that file says rather than what >> I'm saying now). >> >> My understanding was that the way that they've generalised the pixel >> plotting step to support different drawing modes and to do viewport >> testing within the line routine means that the ROM routines would be >> slower than my RAM routines. My routines benefit from only ever doing >> one of two things: >> >> - drawing a solid, single pixel wide line that is definitely entirely >> on the screen (ie, no need to test per pixel) >> - erase an old line, being allowed also to blank out any other pixels >> the routine feels like (which in practice means that it calculates the >> correct (x, y) for each pixel then just zeroes that byte in video >> memory, actually blanking two pixels) >> >> The latter could probably be faster if you halved the notional x >> resolution in which you're drawing and blanked out four pixels rather >> than two (to deal with occasions when the rounded version pixels the >> byte one to the side of the one that the non-rounded routine would >> have picked). I haven't experimented there. >> >> On Thu, May 27, 2010 at 3:19 PM, Roger Jowett wrote: >>> how are lines drawn using rom routine or your own? >>> >>> On 27 May 2010 15:14, Thomas Harte wrote: >>>> Removing hidden line removal would save the time calculating face >>>> visibility but then add to transformation and drawing costs. >>>> >>>> The code at present always does a calculation for every defined face, >>>> always considers a calculation for every defined line and performs >>>> calculations for vertices only if they are used as part of the model >>>> as it is visible for that draw operation. Vertices that are connected >>>> only to lines that aren't visible aren't transformed. >>>> >>>> If I were to rewrite it, I would adjust that so that, as a first >>>> measure, a calculation is performed for every defined face but lines >>>> that aren't connected to visible faces are never even considered. >>>> That's not a massive win in performance terms because all it does for >>>> lines at the minute is run through reading a couple of flags and >>>> proceeding or discarding based on the combination of those. However, >>>> if I were then able to add a broad phase to the face stuff* then it'd >>>> really start to pay off down the hierarchy. >>>> >>>> * as in, a prepatory step that interrogates some sort of hierarchical >>>> structure and hence discards large swathes of faces without doing a >>>> calculation for each. Usually it saves time even if it is able to >>>> reject, say, only 90% of invisible faces and then you have to do the >>>> face-by-face tests on each of the remaining potentially visible set. >>>> I've never been 100% on the best, or even a necessarily suitable >>>> hierarchical form. >>>> >>>> On Thu, May 27, 2010 at 12:51 PM, Roger Jowett >>>> wrote: >>>>> so no hidden line removal speeds things up a bit... >>>>> http://www.worldofspectrum.org/infoseekid.cgi?id=0003126 >>>>> theres a screen shot only the roads were solid line the objects seemed >>>>> to be dots and not hidden line either >>>
Re: Some SAM hardware for sale
I would be _hugely_ surprised if my code was anywhere near as fast as code could be. I would be similarly surprised if I ever run out of ideas for making it faster, at least with the amount of time I ever have for trying these ideas. I recall having to buy a new membrane for my Sam back in the day... given that the original Sam I had also stopped outputting in colour at one point, I do wonder about the build quality. For the record, I'm actually quite knowledegable on some bits of Freescape, having written an OpenGL version that accepts original 3d Construction Kit files. Apart from the obvious stuff of being filled versus empty, a major difference is that the entire scene in Freescape uses 8 bit coordinates. So there's a limited precision on shapes and placement — my code uses 2.8 format for individual models and places them in a 16bit space, giving a much larger play area and precision on individual objects. I also allow individual objects to have local transformations (so, e.g., a ship may rotate on the spot independently of whatever the camera is doing). In Freescape everything is completely fixed. You actually gain quite a lot from completely fixed objects. Because you've no matrix composition step, precision is much less of a problem. The eye space coordinates of each point in my engine are the scalar combination of the result of three sets of four multiplications. The eye space coordinates of each point in Freescape are calculated with only three multiplications in total. In my engine most of the multiplications are done once per model rather than once per vertex as a natural consequence of matrix composition, but problems with accuracy nevertheless require larger fields to be thrown at the problem. I've never looked at the original code, but I'll bet Freescape uses 8bit matrix entries and a 512 byte f(x) = (x^2)/4 table with x in 8bit and f(x) 16bit, meaning that the transform from object to eye space is extremely cheap. And neatly set up for the weird addressing modes of 6502s. That all being said, I want to get the best performance because I want to have done the best job I can. That being said, writing the code is obviously just for the puzzle solving fun, so stealing someone else's code wouldn't really be useful. On Fri, May 28, 2010 at 3:40 PM, Roger Jowett wrote: > http://www.worldofspectrum.org/infoseek.cgi?regexp=^Freescape$&phrase&loadpics=1 > > freescapes are all here and look mostly 48 > pity tthe search criteria cant handle more than one option... > > On 28 May 2010 15:37, Roger Jowett wrote: >> chris asked me to delete the ix and iy from the lemmings code! >> it would have taken me years! mind you my sam keybaord membrane was >> wokring in 92! now i have atom lite and no keybaord membrane working >> from 3 machines! >> you seem to be optimising your 3d routines >> were there any 48 routines that are faster there was so much 3d >> software on the 48: full list from wos >> >> http://www.worldofspectrum.org/infoseek.cgi?regexp=^Vector+Graphics$&phrase&loadpics=1 >> >> elite 3? >> http://www.worldofspectrum.org/infoseek.cgi?regexp=^Elite+3+Novosibirsk$&pub=^Shadow+Soft$&loadpics=1 >> >> someones taking the mikey?! >> >> was thinking along the lines of >> artic 3d combat zone >> melbourne starion >> crl tau ceti >> nexus micronaut one >> rainbird/firebird starglider1&2 carrier command elite >> ocean battle command >> realtime starstrike 1&2 >> mikrosphere sky ranger >> electric dream i of the mask >> microprose f15 project stealth fighterf19 gunship >> novagen mercenary &escape from targ >> activision fighter bomber >> and ofcourse digital integration >> >> velesoft reckon the external ram mb gives sam control over a single >> 16kb page i thought the hmpr controlled the external ram port but >> there doesnt seem toeb anything in the technicial manual about how to >> page it - other than it would page in the same way as teh internal >> ram? >> >> 28 May 2010 12:19, Thomas Harte wrote: >>> Actually, 3 or 4 for the cube, now I think about it. But you get the >>> point. Always nicer when you realise that what you're doing exactly >>> fits an extremely well-documented and well-known data structure and >>> algorithm. >>> >>> On Fri, May 28, 2010 at 8:54 AM, Thomas Harte >>> wrote: >>>> I had one further thought on this overnight: if you expand the planes >>>> bounding a convex object out to infinity then you get a series of >>>> convex cells surrounding the object. Which cell you're in exactly >>>> determines which faces you can see and the natural way t
Re: Some SAM hardware for sale
Freescape was everything available at the time — z80, 6502, 68000 and 8086. And it has a scripting language, with all game events handled by running the bytecode compiled output of that, though by Construction Kit time the model format and scripting language for the 16bit machines is almost entirely different to that for the 8bits. As I recall, there's one bytecode for games pre-Castle Master then another subsequently, so the split probably happened somewhere just before the development of that. Freescape doesn't do networking... On Fri, May 28, 2010 at 4:24 PM, Roger Jowett wrote: > freescape was 6502? thoght the first version was cpc (not+!) > was 6502 1mhz equivalent to z80 at 4mhz? - what ahsame no one bothered > to add patches forthe 4mhz z80 in the fdd3k - or was the serial > interface 9600 baud like the interface 1/128k machines? > > so the r800 16 bit multiply would come in handy along with the lack of > four tstates to each instruction unless its come from the next 256kb > ram boundary - mind you the v9990 seems to have so much hardware > frippery - daft 125 hardware sprites scrolling and blitter - instead > of fixing the maximum bpp colour depth to 256 colours from a 24bit tru > colour palette but allowing a horizontal video ram page switch every > 256 pixels - could diplay 24bit tru colour screens with ¼ of teh video > ram of a pc with further video ram savings if there were less than 256 > different colours on each 256 pixel line of higher than 256 pixels per > horzontal line of the screen - not that it matters > pc seems to drop screen resolution when you run dxdiag for display > testing of textured box regardless of the lcd screen montiors fixed > video display mode - lcd screen quite happily displays a screen > reoslution too low for this monitor error message - infact most > emulators happily use older lower screen resolutions for full screen > simcoupe in a window when dragged off the left hand border of rthe > screen acyually squeezes the 3d vector stuff your routines are drawing > - seems kind of weird that overlays are not use to fix the screen > resolution at the lcd screens best mode and just use multiple pixels - > most 3d chipsets should be capable of doing this even if they cant be > bothered to include int he driver a routine for encoding to video the > desktop or a 3d app - especially when most of the vga cards i have > actually include a tv encoder chip on the vga! > > can your gl freescape network to a real sam using the pc gameport midi > network on the sam?/rs232 comms interface? > > On 28 May 2010 15:58, Thomas Harte wrote: >> I would be _hugely_ surprised if my code was anywhere near as fast as >> code could be. I would be similarly surprised if I ever run out of >> ideas for making it faster, at least with the amount of time I ever >> have for trying these ideas. >> >> I recall having to buy a new membrane for my Sam back in the day... >> given that the original Sam I had also stopped outputting in colour at >> one point, I do wonder about the build quality. >> >> For the record, I'm actually quite knowledegable on some bits of >> Freescape, having written an OpenGL version that accepts original 3d >> Construction Kit files. Apart from the obvious stuff of being filled >> versus empty, a major difference is that the entire scene in Freescape >> uses 8 bit coordinates. So there's a limited precision on shapes and >> placement — my code uses 2.8 format for individual models and places >> them in a 16bit space, giving a much larger play area and precision on >> individual objects. I also allow individual objects to have local >> transformations (so, e.g., a ship may rotate on the spot independently >> of whatever the camera is doing). In Freescape everything is >> completely fixed. >> >> You actually gain quite a lot from completely fixed objects. Because >> you've no matrix composition step, precision is much less of a >> problem. The eye space coordinates of each point in my engine are the >> scalar combination of the result of three sets of four >> multiplications. The eye space coordinates of each point in Freescape >> are calculated with only three multiplications in total. In my engine >> most of the multiplications are done once per model rather than once >> per vertex as a natural consequence of matrix composition, but >> problems with accuracy nevertheless require larger fields to be thrown >> at the problem. I've never looked at the original code, but I'll bet >> Freescape uses 8bit matrix entries and a 512 byte f(x) = (x^2)/4 table >> with x in 8bit and f(x) 16bit, meaning that the transform from object >> to eye space
Re: Porting spectrum games...
Having investigated that specific title in the past, I believe that the Dizzy IP is now co-owned 50:50 by CodeMasters and the Oliver Twins and there is a long standing agreement that people may create whatever fan titles they wish provided that they don't charge for them and include correct credits. So I'm not sure if that would extend to actually disassembling the Spectrum code (though plenty of other titles rip off the original series graphics), but putting out a version of Dizzy for the Sam shouldn't lead to legal troubles in principle. I guess with something like Dizzy you've got a huge advantage because quite probably the hardware specific bits would leap right out if you compared the Spectrum disassembly and the Amstrad CPC disassembly. I'm all for an effort to port games, even if it's a rewrite job. I've written a Dizzy engine for the PC before, albeit based more on the Fantastic Adventures-era Dizzy, might dust that off and have another look see. On Thu, Jul 15, 2010 at 2:51 PM, the_wub ! wrote: > Hi all, > > I just made a comment on World of Sam about porting speccy games and > thought it would be worthwhile to post it here as well. > >> I’d be interested in having a go at porting anything from the speccy to the >> Sam though. >> If another dev could help with disassembling the spectrum game and making >> sense of the source I’d be confident enough to add new gfx and sound code >> and I’d be happy to > put in the time to redraw graphics in 16 colours and >> remake any music in e-tracker. >> Dizzy would be great except that it’s a Code Masters game. They might be a >> bit cease-and-desisty about it.. ;) > > My current Sam project is coming together nicely and I'm already > looking ahead for something fun to do before I start on another > original game. > Small games with simple concepts that can be ported quickly rather > than big licences would be the way to go IMO. That way time could be > spent doing several games instead of one bigger one. It would also > minimise the learning curve for me a bit ;) > > So would anyone be interested in helping me get something started in > the near future? > > Rob. >
Re: Porting spectrum games...
I have to admit that my favourite Dizzy game is the console one - the energy bar is present, some of the arcadey spin-off titles have been rolled in to break up the gameplay and there's quite a limited amount of required travelling to the other side of the world just to pick up an object and travel back. Oh, and as far as I recall only a couple of the coins are of the secret 'press action here to reveal it' type, and they're in places where you might press action anyway like behind doors. None of the guessing the loose bit of handrail malarkey. Or, at least, very little. My memory is imperfect. I wonder how many unique screens you could fit into the Sam's memory (with compression) without resorting to a tile map. One of the things that's obvious after Big Red took over is that they switched quite a lot to a more vector style - not sure if it's actual vectors or just really big tiles, but it does make the world look less vanilla somehow. I guess something like PNG (ie, a standard binary compressor + per scanline switching of how graphics are encoded before compression) with a brute force optimiser (ala optipng/etc) would be the smart thing. And it'll likely always be worse than real PNG, so I guess that's a way to get an upper bound... On Sunday, July 18, 2010, the_wub ! wrote: >> I'm more than happy to write a Sam version of the Pooyan music if >> someone wants to do the easy bit and write the rest of the conversion >> ;-) > > ouch! though I guess I deserve that in hindsight! > > I honestly hadn't considered what would be involved with a port and I > had presumed that starting from a spectrum version would be the > easiest way to port anything to the Sam. I had the ST graphics from > Strider ready and everything! ;) > >> Dizzy... Arrggh!! I loathe those games! :-)) > > He's like Morrissey or Marmite it seems, people love him or hate him! >
Re: Porting spectrum games...
I have to admit that my favourite Dizzy game is the console one - the energy bar is present, some of the arcadey spin-off titles have been rolled in to break up the gameplay and there's quite a limited amount of required travelling to the other side of the world just to pick up an object and travel back. Oh, and as far as I recall only a couple of the coins are of the secret 'press action here to reveal it' type, and they're in places where you might press action anyway like behind doors. None of the guessing the loose bit of handrail malarkey. Or, at least, very little. My memory is imperfect. I wonder how many unique screens you could fit into the Sam's memory (with compression) without resorting to a tile map. One of the things that's obvious after Big Red took over is that they switched quite a lot to a more vector style - not sure if it's actual vectors or just really big tiles, but it does make the world look less vanilla somehow. I guess something like PNG (ie, a standard binary compressor + per scanline switching of how graphics are encoded before compression) with a brute force optimiser (ala optipng/etc) would be the smart thing. And it'll likely always be worse than real PNG, so I guess that's a way to get an upper bound... On Sunday, July 18, 2010, the_wub ! wrote: >> I'm more than happy to write a Sam version of the Pooyan music if >> someone wants to do the easy bit and write the rest of the conversion >> ;-) > > ouch! though I guess I deserve that in hindsight! > > I honestly hadn't considered what would be involved with a port and I > had presumed that starting from a spectrum version would be the > easiest way to port anything to the Sam. I had the ST graphics from > Strider ready and everything! ;) > >> Dizzy... Arrggh!! I loathe those games! :-)) > > He's like Morrissey or Marmite it seems, people love him or hate him! >
Re: Debugging - argh
>From the realm of the ridiculous, a RESTful interface for controlling the debugger and reading machine state with the emulator including a miniature HTTP server that exposes the interface (on localhost, at least) would be the absolutely perfect thing. I was looking into drafting a generic spec for such a thing a while ago but didn't get as far as a document. The benefit would be that the debugger was a separate program from the emulator potentially by a different author without either having to impose very far on the other's project. Realistically, it'd mean that your fast, cross-platform emulator can remain largely in SDL and I can write and attach an OS X specific front-end on the emulator (with sufficient extra knowledge to step through the original source code, hopefully), or even write one in Javascript and run it anywhere Sim Coupe can run. When I looked into it, there seemed to be lots of claims of the like of "a complete HTTP server requiring only BSD sockets underneath in less than 2000 lines of C code" around, so I'm not sure that side is the problem. I keep meaning to investigate something similar in my Electron emulator, but time is a problem nowadays. On Tue, Jul 20, 2010 at 4:12 PM, Andrew Collier wrote: > On 20 July 2010 14:03, Simon Owen wrote: >> >> On 19 Jul 2010, at 22:47, Stefan Drissen wrote: >> >> Now hurry along Si and integrate the label.tab in SimIce… ;-) >> >> If it's just symbols you want tied in, I'm sure that can be arranged :) >> >> You may want to ask David to add page information to the label.tab file >> first though. ;-) > > I don't know about Jam, but pyz80 doesn't assume there will be any > correlation between label addresses (i.e. pc assembly addresses set > using ORG) and the physical representation (set using DUMP). This > means it would be quite difficult to associate a page with a symbol > because it's difficult to be certain of the context in which they > might later be used. (It's easy to dump symbol data from pyz80 as > well, of course). > > I don't think either of our assemblers yet generate enough information > to map a DUMP address back to source file lines, though it would > enable some really cool features if they could. I think I'd want to > look at how it's done "properly" before trying to define a file format > for it... > > (Has anyone ever looked into development of Eclipse plug-ins? It isn't > something I've ever tried, but presumably it would be plausible for > the assembler and SimCoupe to be plug-ins to the IDE, which would save > anybody from having to write a UI for this stuff). > >> If you have any other thoughts on what should be added or changed, I'm open >> to suggestions. It got left a bit unfinished when I could do what I needed >> from it to debug SimCoupe itself, but if there are more people using it then >> it's more likely to be worked on. > > I would find a history of breakpoint expressions quite useful. > > Andrew >
Re: Porting spectrum games...
Hmmm, gmail shows that my previous email was sent twice. Apologies to all if that happened, I'll check it isn't happening repeatedly and if it is then I'll try to figure out why. I am perfectly happy saying things just once... I think there are three for the Nes, but the other two are just ports of Treasure Island Dizzy and Prince of Yolkfolk and I'm not sure if they were released here. I've looked into PNG more, and it is actually realistic to use exactly that algorithm on a Sam (albeit that there's no need to be identical in byte streams) — it's just a linear predictor and LZ77 + Huffman on the end. With that in mind, I've downloaded some of the classic Dizzy maps from those places that tile screenshots to produce game maps (in their Amiga versions) and they're all sub 400kb. Most would even fit into 256kb. So, I'm not sure what sort of art burden it creates, but I definitely think it's feasible to do a Dizzy game on the Sam that doesn't use a tile map, but rather has each and every screen hand drawn, which could look fantastic. Adding 1 or 2bit tile maps for collisions shouldn't be a memory killer. Probably automatically generating a collision map from the source art is easiest? If the designer can save out three layers — a background, middleground and foreground then an external tool can auto build a collision map for the middleground then composite the three to store as the actual screen (so it's one graphic + one collision map in game). Though if we have a foreground then I guess we need a pixel mask somewhere for sprites, which costs yet more bytes. That all being said, it's a disc-based machine so multiloads aren't a problem, are they? I vote aim high and break the world into chunks if we overshoot. I wrote a little Dizzy engine for the PC once, but have never built it for Windows (it's SDL) and was based on the PC sprites and metrics on a scrolling tile map. So it's not directly useful. Probably best to agree an assembler (I'm fine with pyz80 or Jam) and what information you need for screen management, then I can dash off and have a go at some of this screen compression stuff, hopefully to be slotted onto your test screen? How about two pages for the current screen, each filled with the same data by the screen decompressor, which is (in order): 24576 bytes; normal screen image 6144 bytes; mask image — bit set = that pixel is in front of the character sprites, bit clear = that pixel is behind, same bit layout as a Mode 2 screen 768 bytes; collision tile map. 32x24 entries, each a byte in length, linear left-to-right, top-to-bottom as per Mode 1 attributes. Just use 0 = empty, 1 = solid for now? Then there are 1280 spare bytes which my code explicitly won't touch, so anything you would use for cleaning up can go in there. On Tue, Jul 20, 2010 at 8:19 PM, the_wub ! wrote: > The only console version I know is the Nes one and I haven't explored > it much.. I'm more familiar with the ST versions but the two are not > too far apart graphically. I wouldn't like to have to design as many > levels as you could possibly fit in though! ;) > > I'd like to have a go at re-creating the Nes sprites and movement > routines on a test screen. If I got something like that working would > it go some way towards helping if combined with more graphics and your > map ideas? >
Re: Porting spectrum games...
With foreground, middleground and background you'd be defining graphics which the sprites don't interact with and which they move in front of (that's the background), graphics which the sprites do collide with (the middleground; everything the player actually walks on/against/etc) and graphics which the sprites don't interact with and which they move behind of (everything in the foreground). So it's just a way of describing what's in front of and what's behind the player and what the player actually walks on (which I guess also would be nominally behind for drawing purposes, though overlap should be relatively limited). I've no idea how large a single screen will be on average... as I say, it looks likely we could get an entire existing game into memory from PNGs downloaded, but it's probably worth thinking of the PNG file size as an absolute best case. The PNG decompression algorithm doesn't look too taxing, which is why it's a good comparison — we're benefitting from lots of clever people having already addressed the problem and fully documented their solution. If on-screen objects can be in front of as well as behind the player then we can't embed collision information in the screen graphic, since e.g. if Dizzy walks behind a large tree then we have no way of knowing what he's walking amongst short of dedicating an entire bit to it and cutting the map palette to 8 colours. Though if we were to cut the map palette to 8 colours then I'd think the spare bit would be better used as a sort of lighting marker. Split the palette into a light half and a dark half and write the sprite routines to set e.g. the three lowest bits but preserve the top bit and we can define areas of light and shadow for the sprites. Just a thought, probably not worth following up. So, ummm, I'm not sure what you want to do about that. One solution that fits the hardware well is: (1) screen buffer, standard format (2) collision buffer, 1bit buffer, bit set for solid, bit clear for empty, half width resolution, so 128x192 for 3072 bytes total (3) in-front/behind buffer, same format as the collision buffer Which all together make exactly 30kb, pleasingly short of a page. The good fit is that using half-width buffers for (2) and (3) aligns those with with byte boundaries for pixel plotting. Both pyz80 and Jam are supersets of the Comet syntax, but I'm not sure what tools would be used to actually convert source back and forth (since I think it's stored tokenised on the Sam?). The source for my old Dizzy thing is at http://members.allegro.cc/ThomasHarte/files/dizzy/DizzySource.zip and relies on SDL, SDL_image and DUMB for music. It's also a few years old, so likely horribly formatted and barely commented. It's only recently I've started doing this for a living. There's a built OS X binary at http://members.allegro.cc/ThomasHarte/files/dizzy/DizzyOSX.zip. If you build and play then there's the Crash mini-Dizzy followed by some other stuff I was experimenting with. And it's all tilemap based, because I can't draw for toffee and was just messing about anyway. The Nes Dizzy probably isn't the one to go for with all its complicated scrolling and minigames, but I've always had a soft spot for Fantasy World Dizzy. Fancy giving that one a go? On Thu, Jul 22, 2010 at 10:33 AM, the_wub ! wrote: > The Nes Dizzy I've seen is the first one, Dizzy the Adventurer. I'd > forgotten how good it was, even without an energy bar.. > > So what size can a single 24kb screen compress down to? Hand drawn > screens would be amazing. > I've never used 1 or 2 bit tile maps for collision before so it would > be great to learn this. I couldn't immediately see how it could be > generated from the screen image itself though. For the test I would > have sacrificed colour 0 for a duplicate black to out-line solid > objects with. Collision could be detected from just the screen image > itself but the collision tile map could be generated from a screen > like that too. > > I'm not sure why there needs to be a foreground and background if the > screens will be hand drawn? I was going to arrange the palette so > several colours could be variable too, would this be a problem? > >> That all being said, it's a disc-based machine so multiloads aren't a >> problem, are they? I vote aim high and break the world into chunks if >> we overshoot. > > I wouldn't have a problem with that.. > >> I wrote a little Dizzy engine for the PC once, but have never built it >> for Windows (it's SDL) and was based on the PC sprites and metrics on >> a scrolling tile map. So it's not directly useful. > > I'm familiar with SDL so that would probably help a bit! > > I don't know what to say about the assembler option. I'm working on > the real hardware and with Sim Coupe and I really want to carry on > doing so at it is tremendous fun :) That said I can see the benefit > of working with modern tools so maybe some sort of compromise could be > reached? > > As to the screen format you p
Re: Porting spectrum games...
Console Dizzy is quite clearly tile based for both graphics and collision. If I recall, Dizzy himself is three tiles high and when crossing a tile boundary may walk left or right provided that both of the top two tiles are clear. If he ends up with a tile overlapping his bottom third then he's pushed up one pixel/frame (or, possibly not exactly that number, but you get the point), to give a sort of soft boundary. Then if you're moving up a hill or whatever, he moves smoothly rather than hopping up a tile at a time. In the little PC Dizzy thing I wrote, that makes everything as simple as grab the up-to-twelve tiles that Dizzy is currently overlapping (he's two wide, so if not aligned exactly with the background may cover up to three tiles across and four tiles down), then make a decision purely on the coverage of those. If he has come to overlap somewhere with the top two tiles on his left or right, or any tiles above him then he gets an instantaneous push out of those blocks. If his feet are covered then he gets a soft push upwards. So there's no continuous state for collisions beyond his current position. And if he's rolling then he stops only if at the end of roll, with his feet on the ground. It's simple and super robust, while still being accurate to at least one real Dizzy. I guess that the same general stuff applies as you scale down the tilemap (all the way to 1 pixel, if you want), just the constants that go up. 256x192 1bpp would mean that an over/under mask doesn't fit onto the same page as a collision map and the framebuffer, so assuming it's better to keep over/under and collisions in the same format so that code is smaller and neater, I guess you want over/under placed immediately after the framebuffer and duplicated across both video pages (as you'll need it when drawing, and that makes paging easy), the collisions map placed somewhere else, with just one copy? Samflate will definitely get us off to a good start with graphics compression, as deflate is the main complicated part of it. The rest of it is just the linear predictor that dictates one of a small number of ways of predicting the next pixel (based on simple sums of the pixel to its left, the pixel above it and the pixel to its top left) and then stores the amount by which the prediction is wrong, the stream of those quantities tending to compress a lot better than raw pixel values. Quite probably Andrew's code will end up being 90% of the code for screen decompression. Or maybe 100%, depending on how well vanilla deflate does on the Fantasy World Dizzy map. Andrew's code comes with a pyz80 makefile, so that's the immediate candidate. I was planning to move my 3d stuff to Jam for the macros, but I guess Comet doesn't support those anyway? If we're saying Comet is the syntax and both Jam and pyz80 superset Comet then I guess it's academic which we use and we needn't even both use the same... On Thu, Jul 22, 2010 at 12:36 PM, the_wub ! wrote: > Yes, Dizzy seems to have near pixel perfect collision, at least for > defining the terrain. I thought the bitmap would be 256x192 bits; > 0=empty, 1=solid? that would be 6144bytes per screen. >
Re: Porting spectrum games...
Right, so... framebuffer, 1bit per pixel over/under map, 1bit per tile 8x8 collision map? For a total of 30816 bytes? I'll assume that we're using 64kb for the two screen buffers, 64kb for main game code and music/sound, meaning that the map would ideally break into 96kb segments (for multiloading, with DOS still resident on a 256kb machine) and be less than or equal to 384kb total (for a single load on a 512kb machine, meaning we don't need DOS in memory)? On Thu, Jul 22, 2010 at 3:10 PM, the_wub ! wrote: > I've been playing with the speccy version on the Sam this morning and > I can see now the effect of the sprite being pushed up as you walk > into the terrain. > > I'm not clear on how you're going to fit amiga screen shots into the > Sam but I cannot wait to see it! I'll carry on making up a sprite set > and putting together a test screen in the meantime. >
Re: Porting spectrum games...
PNG wasn't a leg pull, though I've been unable to find the Amiga map
for Fantasy World Dizzy. However, the entire PC map (256 colour,
individual screens slightly too large) is 250 kb as a PNG. So it'd be
possible. Animated elements are going to need to be repainted frame by
frame so are logically separate from the background anyway.
I'm unable to get Dizzy.zip ("Permission denied"), but at this point
it does look more like I'll hold you back rather than help you.
On Sun, Jul 25, 2010 at 9:41 PM, the_wub ! wrote:
> I can't take any credit for how things look :) Not only are they the
> work of someone else but the best of the blit routines are by Chris!
>
>> With animations going on, wouldn't it be impractical not to have a tile
>> based system?
>
> I agree, although if PNG files can be used then the time saved not
> having to make tiles could be spent making special instances for the
> animations..
>
Re: Dizzy (was: Porting spectrum games...)
The gamble is that anything cartoony compresses better than anything photographic, that PNG is work subsequent to the Sam's heyday, explaining why we're able to be much more bullish about compression rates and that if the map stops fitting we can just break it into multiload. It may not work, but I think it's worth investigating. That the PC map fits into 250k and the Sam map will have half the bit depth, less than 80% of the pixels and the memory target is 50% larger than that is encouraging. I'm definitely pushing the idea as a way to avoid the look of tiles. I think that look instantly dates a game. On 7/26/10, Stefan Drissen wrote: > Ummm... whats the point in using a png map if the png is based on tiles?!? I > thought the idea for using png was to allow some really nice authentic > graphics to be used that do not look tiley - which the Dizzy map obviously > does. The png idea could be very good for something NOT tile based (SCUMM > anyone?) > > I think the repeating tiles are what are allowing these maps to compress so > well. > > > Stefan > > -Original Message- > From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On > Behalf Of Frode Tennebø > Sent: maandag 26 juli 2010 08:37 > To: sam-users@nvg.ntnu.no > Subject: Re: Porting spectrum games... > > On Sun, 25 Jul 2010 23:54:41 +0200, Thomas Harte > wrote: > >> PNG wasn't a leg pull, though I've been unable to find the Amiga map >> for Fantasy World Dizzy. However, the entire PC map (256 colour, >> individual screens slightly too large) is 250 kb as a PNG. So it'd be >> possible. > > Would this one do: > http://hol.abime.net/pic_full/gamemap/0501-0600/502_gamemap1.png > > It would take some stiching to make it 100% and fit 256 pixels wide. > >> Animated elements are going to need to be repainted frame by >> frame so are logically separate from the background anyway. > > My thought was that animated elements could be tiles in the same way as > static tiles to save any special handling of those for each screen. > However, I guess it would be rather straight forward to generalise > animations as another layer instead? > > -Frode > -- > ^ Frode Tennebø | email: fr...@tennebo.com | fr...@irc ^ > | with Standard.Disclaimer; use Standard.Disclaimer; | > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.851 / Virus Database: 271.1.1/3027 - Release Date: 07/25/10 > 08:36:00 > >
Re: Dizzy (was: Porting spectrum games...)
Further to this: I've been playing around with it today using a couple of the more complicated screens from that Amiga map which didn't feature the watermark (since it's an alpha transparency, causing the number of colours to skyrocket), resized to 256 pixels across (which makes 141 pixels high). For a sensible lower bound on what I should expect, I saved them as PNGs and ran them through OptiPNG, PNGCrush, and AdvPNG, keeping the smallest version. The first (Dylan and a tree) is 5,553 bytes as a PNG. The second (featuring the Armorog) 6,108 bytes. In my quick dash at compression code, I implemented just a trivial little LZ77, using an exhaustive search to pattern match and treating each scan line as a completely separate thing to compress (and, as a result, rounded up to the next full byte). Five bits for a literal, 17 for a back reference, the native addressable thing being a nibble. >From that, I got 6,080 bytes for the first screen and 7,170 for the second. And this is without yet implementing a Huffman tree (probably best done per screen) or any sort of predictor. So, it looks like on a 16 colour display the LZ77 may actually be the most of it. In which case it's going to be hard to support the conclusion that PNG is massively better than the various common techniques when the Sam was a going concern. A Huffman tree is an easy win and something I'll experiment with tomorrow hopefully and a predictor is a useful addition even when dealing with hard edged low colour graphics because it introduces the second dimension as a going concern whereas LZ77 has no concept of that. Would it be possible to get a single screen hand prepared to be really beautiful rather than ripped from a tilemap? On Tue, Jul 27, 2010 at 10:46 AM, Stefan Drissen wrote: > Fair enough. You could of course create PNG tiles so that you do not need to > Flash! anything. You could then even also use a 256-colour PNG image as map > editor, the colour determining the tile... ;-) > > Flashback would be very cool - on the PC I don't remember it having > scrolling. You would however also need to create an animated PNG / MPEG > player for the animated sequences. > > Lots of fun things to do... :-) > > -Original Message- > From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On > Behalf Of the_wub ! > Sent: Monday, July 26, 2010 19:21 > To: sam-users@nvg.ntnu.no > Subject: Re: Dizzy (was: Porting spectrum games...) > > If png's can be used then I think we should do it even if using an > image of tiles is a bit ironic! It would allow changes to be made to > the image in the gimp rather than flash! if nothing else! ;) If a > success, I don't dare to dream about scumm but another possible port > would be Flashback, I can't remember how much if any scrolling is in > there but something would be possible if pngs could be used as source > gfx... > I don't know enough to comment on the feasibility of it all but I do > have a question, why use the PC bitmaps and not the ST? The Atari is > already 16 colours and it would be easy enough to fancy them up a bit, > make them a bit less tiley.. I'm saying this without having a good > look at how the PC gfx would work in 16 colours though... > > Hey Warren! I'd guess that whichever direction the project goes > there'll be tons to do. The more the merrier I say :) > >
Re: Dizzy (was: Porting spectrum games...)
Actually, late night spurt — with Huffman trees it's 5,528 bytes and 6,653 bytes respectively. No predictor yet. The former technically beats the PNG size, but I'd imagine that just means the predictor is barely going to help and I'm gaining a small win by not including any of the normal file padding or headers. Or even the palette. On Tue, Jul 27, 2010 at 11:47 PM, Thomas Harte wrote: > Further to this: I've been playing around with it today using a couple > of the more complicated screens from that Amiga map which didn't > feature the watermark (since it's an alpha transparency, causing the > number of colours to skyrocket), resized to 256 pixels across (which > makes 141 pixels high). For a sensible lower bound on what I should > expect, I saved them as PNGs and ran them through OptiPNG, PNGCrush, > and AdvPNG, keeping the smallest version. > > The first (Dylan and a tree) is 5,553 bytes as a PNG. The second > (featuring the Armorog) 6,108 bytes. > > In my quick dash at compression code, I implemented just a trivial > little LZ77, using an exhaustive search to pattern match and treating > each scan line as a completely separate thing to compress (and, as a > result, rounded up to the next full byte). Five bits for a literal, 17 > for a back reference, the native addressable thing being a nibble. > > From that, I got 6,080 bytes for the first screen and 7,170 for the > second. And this is without yet implementing a Huffman tree (probably > best done per screen) or any sort of predictor. > > So, it looks like on a 16 colour display the LZ77 may actually be the > most of it. In which case it's going to be hard to support the > conclusion that PNG is massively better than the various common > techniques when the Sam was a going concern. A Huffman tree is an easy > win and something I'll experiment with tomorrow hopefully and a > predictor is a useful addition even when dealing with hard edged low > colour graphics because it introduces the second dimension as a going > concern whereas LZ77 has no concept of that. > > Would it be possible to get a single screen hand prepared to be really > beautiful rather than ripped from a tilemap? > > On Tue, Jul 27, 2010 at 10:46 AM, Stefan Drissen > wrote: >> Fair enough. You could of course create PNG tiles so that you do not need to >> Flash! anything. You could then even also use a 256-colour PNG image as map >> editor, the colour determining the tile... ;-) >> >> Flashback would be very cool - on the PC I don't remember it having >> scrolling. You would however also need to create an animated PNG / MPEG >> player for the animated sequences. >> >> Lots of fun things to do... :-) >> >> -Original Message- >> From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On >> Behalf Of the_wub ! >> Sent: Monday, July 26, 2010 19:21 >> To: sam-users@nvg.ntnu.no >> Subject: Re: Dizzy (was: Porting spectrum games...) >> >> If png's can be used then I think we should do it even if using an >> image of tiles is a bit ironic! It would allow changes to be made to >> the image in the gimp rather than flash! if nothing else! ;) If a >> success, I don't dare to dream about scumm but another possible port >> would be Flashback, I can't remember how much if any scrolling is in >> there but something would be possible if pngs could be used as source >> gfx... >> I don't know enough to comment on the feasibility of it all but I do >> have a question, why use the PC bitmaps and not the ST? The Atari is >> already 16 colours and it would be easy enough to fancy them up a bit, >> make them a bit less tiley.. I'm saying this without having a good >> look at how the PC gfx would work in 16 colours though... >> >> Hey Warren! I'd guess that whichever direction the project goes >> there'll be tons to do. The more the merrier I say :) >> >> >
Re: Dizzy (was: Porting spectrum games...)
The previously posted Fantasy World Dizzy map seems to have come from 'Hall of Light', which offers itself as 'the database of Amiga games' at http://hol.abime.net/. You can't just chop up the map and reuse it though, as they've watermarked it with an alpha transparency. It's large but quite spaced out, so I've just used screens that the watermark doesn't touch. And probably if you had a piece of software that was at all competent at reducing colour depth then you'd be able to wash it off again. On Wed, Jul 28, 2010 at 10:03 AM, Stefan Drissen wrote: > For Amiga Treasure Island Dizzy: > > http://www.vgmaps.com/Atlas/Amiga/TreasureIslandDizzy-TreasureIsland.png > > The www.vgmaps.com site has quite a few more cool maps (for example the > Flashback ones in my previous post). > > > Stefan > > > -Original Message- > From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On > Behalf Of Andrew Park > Sent: Wednesday, July 28, 2010 10:29 > To: sam-users@nvg.ntnu.no > Subject: RE: Dizzy (was: Porting spectrum games...) > > It is great to see some activity on here again, 1 quick question where did > the amiga dizzy map come from to get screens, i've been looking for good > amiga screenshot maps everywhere as i'm not an artist and this stops me > writing games, i like to see graphical progress when i'm writing. > > Anybody send me a link? > > Andy > > -Original Message- > From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On > Behalf Of Thomas Harte > Sent: 28 July 2010 00:11 > To: sam-users@nvg.ntnu.no > Subject: Re: Dizzy (was: Porting spectrum games...) > > Actually, late night spurt — with Huffman trees it's 5,528 bytes and > 6,653 bytes respectively. No predictor yet. The former technically > beats the PNG size, but I'd imagine that just means the predictor is > barely going to help and I'm gaining a small win by not including any > of the normal file padding or headers. Or even the palette. > > On Tue, Jul 27, 2010 at 11:47 PM, Thomas Harte > wrote: >> Further to this: I've been playing around with it today using a couple >> of the more complicated screens from that Amiga map which didn't >> feature the watermark (since it's an alpha transparency, causing the >> number of colours to skyrocket), resized to 256 pixels across (which >> makes 141 pixels high). For a sensible lower bound on what I should >> expect, I saved them as PNGs and ran them through OptiPNG, PNGCrush, >> and AdvPNG, keeping the smallest version. >> >> The first (Dylan and a tree) is 5,553 bytes as a PNG. The second >> (featuring the Armorog) 6,108 bytes. >> >> In my quick dash at compression code, I implemented just a trivial >> little LZ77, using an exhaustive search to pattern match and treating >> each scan line as a completely separate thing to compress (and, as a >> result, rounded up to the next full byte). Five bits for a literal, 17 >> for a back reference, the native addressable thing being a nibble. >> >> From that, I got 6,080 bytes for the first screen and 7,170 for the >> second. And this is without yet implementing a Huffman tree (probably >> best done per screen) or any sort of predictor. >> >> So, it looks like on a 16 colour display the LZ77 may actually be the >> most of it. In which case it's going to be hard to support the >> conclusion that PNG is massively better than the various common >> techniques when the Sam was a going concern. A Huffman tree is an easy >> win and something I'll experiment with tomorrow hopefully and a >> predictor is a useful addition even when dealing with hard edged low >> colour graphics because it introduces the second dimension as a going >> concern whereas LZ77 has no concept of that. >> >> Would it be possible to get a single screen hand prepared to be really >> beautiful rather than ripped from a tilemap? >> >> On Tue, Jul 27, 2010 at 10:46 AM, Stefan Drissen >> wrote: >>> Fair enough. You could of course create PNG tiles so that you do not need > to >>> Flash! anything. You could then even also use a 256-colour PNG image as > map >>> editor, the colour determining the tile... ;-) >>> >>> Flashback would be very cool - on the PC I don't remember it having >>> scrolling. You would however also need to create an animated PNG / MPEG >>> player for the animated sequences. >>> >>> Lots of fun things to do... :-) >>> >>> -Original Message- >>> From: owner-sam-us...@nvg.ntnu.no [ma
Re: Dizzy (was: Porting spectrum games...)
Hmmm, not doing very well with the Flashback image I chose to test (the top left screen) at all. PNG is 10,649 bytes and I'm 13,507 bytes. But unlike yesterday, that's with the Huffman tree stored (whoops!) and the palette thrown on. I've also tweaked the LZ77 stage a bit, so it's now a 256 pixel rolling buffer with repetitions up to 18 pixels in length and the entire screen compressed as one block. That said, at one point the storage space for all three images seemed to go up by about 1.5kb for absolutely no reason. So I don't thoroughly trust my code. I've tried sorting the palette by hue (to give it some sort of likelihood that nearby colours are near each other in the palette) and applying the various PNG prediction filters to the entire image with each and every one causing the file size to grow. Which is quiet probably why PNG picks them line by line. So that's the experiment for tomorrow night... On Wed, Jul 28, 2010 at 10:53 AM, Thomas Harte wrote: > The previously posted Fantasy World Dizzy map seems to have come from > 'Hall of Light', which offers itself as 'the database of Amiga games' > at http://hol.abime.net/. You can't just chop up the map and reuse it > though, as they've watermarked it with an alpha transparency. It's > large but quite spaced out, so I've just used screens that the > watermark doesn't touch. And probably if you had a piece of software > that was at all competent at reducing colour depth then you'd be able > to wash it off again. > > On Wed, Jul 28, 2010 at 10:03 AM, Stefan Drissen > wrote: >> For Amiga Treasure Island Dizzy: >> >> http://www.vgmaps.com/Atlas/Amiga/TreasureIslandDizzy-TreasureIsland.png >> >> The www.vgmaps.com site has quite a few more cool maps (for example the >> Flashback ones in my previous post). >> >> >> Stefan >> >> >> -Original Message- >> From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On >> Behalf Of Andrew Park >> Sent: Wednesday, July 28, 2010 10:29 >> To: sam-users@nvg.ntnu.no >> Subject: RE: Dizzy (was: Porting spectrum games...) >> >> It is great to see some activity on here again, 1 quick question where did >> the amiga dizzy map come from to get screens, i've been looking for good >> amiga screenshot maps everywhere as i'm not an artist and this stops me >> writing games, i like to see graphical progress when i'm writing. >> >> Anybody send me a link? >> >> Andy >> >> -Original Message- >> From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On >> Behalf Of Thomas Harte >> Sent: 28 July 2010 00:11 >> To: sam-users@nvg.ntnu.no >> Subject: Re: Dizzy (was: Porting spectrum games...) >> >> Actually, late night spurt — with Huffman trees it's 5,528 bytes and >> 6,653 bytes respectively. No predictor yet. The former technically >> beats the PNG size, but I'd imagine that just means the predictor is >> barely going to help and I'm gaining a small win by not including any >> of the normal file padding or headers. Or even the palette. >> >> On Tue, Jul 27, 2010 at 11:47 PM, Thomas Harte >> wrote: >>> Further to this: I've been playing around with it today using a couple >>> of the more complicated screens from that Amiga map which didn't >>> feature the watermark (since it's an alpha transparency, causing the >>> number of colours to skyrocket), resized to 256 pixels across (which >>> makes 141 pixels high). For a sensible lower bound on what I should >>> expect, I saved them as PNGs and ran them through OptiPNG, PNGCrush, >>> and AdvPNG, keeping the smallest version. >>> >>> The first (Dylan and a tree) is 5,553 bytes as a PNG. The second >>> (featuring the Armorog) 6,108 bytes. >>> >>> In my quick dash at compression code, I implemented just a trivial >>> little LZ77, using an exhaustive search to pattern match and treating >>> each scan line as a completely separate thing to compress (and, as a >>> result, rounded up to the next full byte). Five bits for a literal, 17 >>> for a back reference, the native addressable thing being a nibble. >>> >>> From that, I got 6,080 bytes for the first screen and 7,170 for the >>> second. And this is without yet implementing a Huffman tree (probably >>> best done per screen) or any sort of predictor. >>> >>> So, it looks like on a 16 colour display the LZ77 may actually be the >>> most of it. In which case it's going to be hard t
Re: Dizzy (was: Porting spectrum games...)
I'll wager you can do better at compression than I can at present, as I'm almost completely new to this. But that makes it interesting. It's obviously wrong to focus too heavily on any test set, but I've bundled together the five images I'm currently testing with, in their optimal PNG forms, and uploaded to http://members.allegro.cc/ThomasHarte/temp/SamTestScreens.zip You should get files screen1 to screen5 (two from Dizzy, three from Flashback) which as PNGs are sized 5,553, 6,108, 10,643, 10,005 and 11,533 bytes respectively. The only thing implicit in my output data is that the images are 256 pixels wide. Not all are 192 pixels high but the height is left implicit from the total number of pixels. Palettes are included with the images. With that in mind, I'm currently at 5,531, 7,273, 11,956, 10,538 and 12,367 bytes. But still working on it. So I won't take offence if you embarrass me thoroughly... On Thu, Jul 29, 2010 at 4:18 PM, Adrian Brown wrote: > I hope these will support the EEPROM highscore saving or similar ;). Ive got > some strange compression modes, bung me the image and ill see how well i can > compress it. Good to see people looking at the Sam again. Im hoping to get > some more time on Sam Uip soon > > Adrian > > -Original Message- > From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On > Behalf Of Thomas Harte > Sent: 28 July 2010 22:31 > To: sam-users@nvg.ntnu.no > Subject: Re: Dizzy (was: Porting spectrum games...) > > Hmmm, not doing very well with the Flashback image I chose to test > (the top left screen) at all. PNG is 10,649 bytes and I'm 13,507 > bytes. But unlike yesterday, that's with the Huffman tree stored > (whoops!) and the palette thrown on. I've also tweaked the LZ77 stage > a bit, so it's now a 256 pixel rolling buffer with repetitions up to > 18 pixels in length and the entire screen compressed as one block. > > That said, at one point the storage space for all three images seemed > to go up by about 1.5kb for absolutely no reason. So I don't > thoroughly trust my code. > > I've tried sorting the palette by hue (to give it some sort of > likelihood that nearby colours are near each other in the palette) and > applying the various PNG prediction filters to the entire image with > each and every one causing the file size to grow. Which is quiet > probably why PNG picks them line by line. So that's the experiment for > tomorrow night... > > On Wed, Jul 28, 2010 at 10:53 AM, Thomas Harte > wrote: >> The previously posted Fantasy World Dizzy map seems to have come from >> 'Hall of Light', which offers itself as 'the database of Amiga games' >> at http://hol.abime.net/. You can't just chop up the map and reuse it >> though, as they've watermarked it with an alpha transparency. It's >> large but quite spaced out, so I've just used screens that the >> watermark doesn't touch. And probably if you had a piece of software >> that was at all competent at reducing colour depth then you'd be able >> to wash it off again. >> >> On Wed, Jul 28, 2010 at 10:03 AM, Stefan Drissen >> wrote: >>> For Amiga Treasure Island Dizzy: >>> >>> http://www.vgmaps.com/Atlas/Amiga/TreasureIslandDizzy-TreasureIsland.png >>> >>> The www.vgmaps.com site has quite a few more cool maps (for example the >>> Flashback ones in my previous post). >>> >>> >>> Stefan >>> >>> >>> -Original Message- >>> From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On >>> Behalf Of Andrew Park >>> Sent: Wednesday, July 28, 2010 10:29 >>> To: sam-users@nvg.ntnu.no >>> Subject: RE: Dizzy (was: Porting spectrum games...) >>> >>> It is great to see some activity on here again, 1 quick question where did >>> the amiga dizzy map come from to get screens, i've been looking for good >>> amiga screenshot maps everywhere as i'm not an artist and this stops me >>> writing games, i like to see graphical progress when i'm writing. >>> >>> Anybody send me a link? >>> >>> Andy >>> >>> -Original Message- >>> From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On >>> Behalf Of Thomas Harte >>> Sent: 28 July 2010 00:11 >>> To: sam-users@nvg.ntnu.no >>> Subject: Re: Dizzy (was: Porting spectrum games...) >>> >>> Actually, late night spurt - with Huffman trees it's 5,528 bytes and >>> 6,653 bytes respectively. No predictor ye
Re: Dizzy (was: Porting spectrum games...)
Oh, but I haven't actually tested the output stream yet. So for all I know, some error is lurking somewhere making my numbers smaller by accidentally throwing data away... On Thu, Jul 29, 2010 at 7:00 PM, Thomas Harte wrote: > I'll wager you can do better at compression than I can at present, as > I'm almost completely new to this. But that makes it interesting. > > It's obviously wrong to focus too heavily on any test set, but I've > bundled together the five images I'm currently testing with, in their > optimal PNG forms, and uploaded to > http://members.allegro.cc/ThomasHarte/temp/SamTestScreens.zip > > You should get files screen1 to screen5 (two from Dizzy, three from > Flashback) which as PNGs are sized 5,553, 6,108, 10,643, 10,005 and > 11,533 bytes respectively. > > The only thing implicit in my output data is that the images are 256 > pixels wide. Not all are 192 pixels high but the height is left > implicit from the total number of pixels. Palettes are included with > the images. > > With that in mind, I'm currently at 5,531, 7,273, 11,956, 10,538 and > 12,367 bytes. But still working on it. So I won't take offence if you > embarrass me thoroughly... > > On Thu, Jul 29, 2010 at 4:18 PM, Adrian Brown > wrote: >> I hope these will support the EEPROM highscore saving or similar ;). Ive >> got some strange compression modes, bung me the image and ill see how well i >> can compress it. Good to see people looking at the Sam again. Im hoping to >> get some more time on Sam Uip soon >> >> Adrian >> >> -Original Message- >> From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On >> Behalf Of Thomas Harte >> Sent: 28 July 2010 22:31 >> To: sam-users@nvg.ntnu.no >> Subject: Re: Dizzy (was: Porting spectrum games...) >> >> Hmmm, not doing very well with the Flashback image I chose to test >> (the top left screen) at all. PNG is 10,649 bytes and I'm 13,507 >> bytes. But unlike yesterday, that's with the Huffman tree stored >> (whoops!) and the palette thrown on. I've also tweaked the LZ77 stage >> a bit, so it's now a 256 pixel rolling buffer with repetitions up to >> 18 pixels in length and the entire screen compressed as one block. >> >> That said, at one point the storage space for all three images seemed >> to go up by about 1.5kb for absolutely no reason. So I don't >> thoroughly trust my code. >> >> I've tried sorting the palette by hue (to give it some sort of >> likelihood that nearby colours are near each other in the palette) and >> applying the various PNG prediction filters to the entire image with >> each and every one causing the file size to grow. Which is quiet >> probably why PNG picks them line by line. So that's the experiment for >> tomorrow night... >> >> On Wed, Jul 28, 2010 at 10:53 AM, Thomas Harte >> wrote: >>> The previously posted Fantasy World Dizzy map seems to have come from >>> 'Hall of Light', which offers itself as 'the database of Amiga games' >>> at http://hol.abime.net/. You can't just chop up the map and reuse it >>> though, as they've watermarked it with an alpha transparency. It's >>> large but quite spaced out, so I've just used screens that the >>> watermark doesn't touch. And probably if you had a piece of software >>> that was at all competent at reducing colour depth then you'd be able >>> to wash it off again. >>> >>> On Wed, Jul 28, 2010 at 10:03 AM, Stefan Drissen >>> wrote: >>>> For Amiga Treasure Island Dizzy: >>>> >>>> http://www.vgmaps.com/Atlas/Amiga/TreasureIslandDizzy-TreasureIsland.png >>>> >>>> The www.vgmaps.com site has quite a few more cool maps (for example the >>>> Flashback ones in my previous post). >>>> >>>> >>>> Stefan >>>> >>>> >>>> -Original Message- >>>> From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On >>>> Behalf Of Andrew Park >>>> Sent: Wednesday, July 28, 2010 10:29 >>>> To: sam-users@nvg.ntnu.no >>>> Subject: RE: Dizzy (was: Porting spectrum games...) >>>> >>>> It is great to see some activity on here again, 1 quick question where did >>>> the amiga dizzy map come from to get screens, i've been looking for good >>>> amiga screenshot maps everywhere as i'm not an artist and this stops me >>>> writing games
Re: Dizzy (was:Porting spectrum games...)
They're 16 colour (quite poorly in one case), but not necessarily using colours actually available on the Sam's. I've appended the correct number of bits to store a Sam palette after the compressed region. I've also discovered a bug that makes all my numbers worse. I'm tapping this on the bus so can't give you actual numbers but it's of the order of 6.something kb for the first and 7 or 8 for the second. I'm hoping to be able to shrink again, as right now I'm doing no better than standard deflate, I think. On Friday, July 30, 2010, Adrian Brown wrote: > Thanks, ill have a quick go. The only thing wil be PNG is a very good format > for compression. Are these colour reduced to sam already or not? > > Adrian > > -Original Message- > From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On > Behalf Of Thomas Harte > Sent: 29 July 2010 19:31 > To: sam-users@nvg.ntnu.no > Subject: Re: Dizzy (was: Porting spectrum games...) > > Oh, but I haven't actually tested the output stream yet. So for all I > know, some error is lurking somewhere making my numbers smaller by > accidentally throwing data away... > > On Thu, Jul 29, 2010 at 7:00 PM, Thomas Harte > wrote: >> I'll wager you can do better at compression than I can at present, as >> I'm almost completely new to this. But that makes it interesting. >> >> It's obviously wrong to focus too heavily on any test set, but I've >> bundled together the five images I'm currently testing with, in their >> optimal PNG forms, and uploaded to >> http://members.allegro.cc/ThomasHarte/temp/SamTestScreens.zip >> >> You should get files screen1 to screen5 (two from Dizzy, three from >> Flashback) which as PNGs are sized 5,553, 6,108, 10,643, 10,005 and >> 11,533 bytes respectively. >> >> The only thing implicit in my output data is that the images are 256 >> pixels wide. Not all are 192 pixels high but the height is left >> implicit from the total number of pixels. Palettes are included with >> the images. >> >> With that in mind, I'm currently at 5,531, 7,273, 11,956, 10,538 and >> 12,367 bytes. But still working on it. So I won't take offence if you >> embarrass me thoroughly... >> >> On Thu, Jul 29, 2010 at 4:18 PM, Adrian Brown >> wrote: >>> I hope these will support the EEPROM highscore saving or similar ;). Ive >>> got some strange compression modes, bung me the image and ill see how well >>> i can compress it. Good to see people looking at the Sam again. Im hoping >>> to get some more time on Sam Uip soon >>> >>> Adrian >>> >>> -Original Message- >>> From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On >>> Behalf Of Thomas Harte >>> Sent: 28 July 2010 22:31 >>> To: sam-users@nvg.ntnu.no >>> Subject: Re: Dizzy (was: Porting spectrum games...) >>> >>> Hmmm, not doing very well with the Flashback image I chose to test >>> (the top left screen) at all. PNG is 10,649 bytes and I'm 13,507 >>> bytes. But unlike yesterday, that's with the Huffman tree stored >>> (whoops!) and the palette thrown on. I've also tweaked the LZ77 stage >>> a bit, so it's now a 256 pixel rolling buffer with repetitions up to >>> 18 pixels in length and the entire screen compressed as one block. >>> >>> That said, at one point the storage space for all three images seemed >>> to go up by about 1.5kb for absolutely no reason. So I don't >>> thoroughly trust my code. >>> >>> I've tried sorting the palette by hue (to give it some sort of >>> likelihood that nearby colours are near each other in the palette) and >>> applying the various PNG prediction filters to the entire image with >>> each and every one causing the file size to grow. Which is quiet >>> probably why PNG picks them line by line. So that's the experiment for >>> tomorrow night... >>> >>> On Wed, Jul 28, 2010 at 10:53 AM, Thomas Harte >>> wrote: >>>> The previously posted Fantasy World Dizzy map seems to have come from >>>> 'Hall of Light', which offers itself as 'the database of Amiga games' >>>> at http://hol.abime.net/. You can't just chop up the map and reuse it >>>> though, as they've watermarked it with an alpha transparency. It's >>>> large but quite spaced out, so I've just used screens that the >>>> watermark doesn't touch. And probably if you had a piece of software >>>> that was at all competent at reducing colour depth then you'd be able >>>> to wash it off again. >>>> >>>> On Wed, Jul 28, 2010 at 10:03 AM, Stefan Drissen >>>> wrote: >>>>> For Amiga Treasure Island Dizzy: >>>>> >>>>> http://www.vgmaps.com/Atlas/Amiga/TreasureIslandDizzy-Trea
Re: Dizzy (was:Porting spectrum games...)
It looks better and it means that the off-the-shelf tools for creating screens are substantially more advanced, being things like Photoshop, and the skills for creating them are much more widespread. If people are willing to help, they just need to use whatever they normally use. Even at gzip level compression you're probably safe to get the 60 screens of Fantasy World Dizzy onto a disk, so going multiload is a sufficient safety net. Cartoon-style graphics generally compress quite well in any case, so it's not unrealistic to hope that the 60 screens can be stored simultaneously in 512 kb along with the rest of the program. PNG then came into it as evidence of how compact you can make graphics using well-documented algorithms. That I happen to be using screenshots grabbed from tile-based games for testing is just because 16 colour games were often tile based and reducing colour on higher colour screenshots tends to lead to large areas of solid colour that may not be a realistic test. I have also been testing downsampled screens from things like Day of the Tentacle, getting size reductions still in the 40+% range but the tool I have for palette reductions is really rather useless so I'm not putting any substantial weight on that. On Fri, Jul 30, 2010 at 11:20 AM, Adrian Brown wrote: > Cant remember, was there a reason for individual png and not tile systems > like the originals used. In Flashback (IIRC) it uses multi layer maps > > Adrian > > -Original Message- > From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On > Behalf Of Thomas Harte > Sent: 30 July 2010 11:15 > To: sam-users@nvg.ntnu.no > Subject: Re: Dizzy (was:Porting spectrum games...) > > They're 16 colour (quite poorly in one case), but not necessarily > using colours actually available on the Sam's. I've appended the > correct number of bits to store a Sam palette after the compressed > region. > > I've also discovered a bug that makes all my numbers worse. I'm > tapping this on the bus so can't give you actual numbers but it's of > the order of 6.something kb for the first and 7 or 8 for the second. > I'm hoping to be able to shrink again, as right now I'm doing no > better than standard deflate, I think. > > On Friday, July 30, 2010, Adrian Brown > wrote: >> Thanks, ill have a quick go. The only thing wil be PNG is a very good >> format for compression. Are these colour reduced to sam already or not? >> >> Adrian >> >> -Original Message- >> From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On >> Behalf Of Thomas Harte >> Sent: 29 July 2010 19:31 >> To: sam-users@nvg.ntnu.no >> Subject: Re: Dizzy (was: Porting spectrum games...) >> >> Oh, but I haven't actually tested the output stream yet. So for all I >> know, some error is lurking somewhere making my numbers smaller by >> accidentally throwing data away... >> >> On Thu, Jul 29, 2010 at 7:00 PM, Thomas Harte >> wrote: >>> I'll wager you can do better at compression than I can at present, as >>> I'm almost completely new to this. But that makes it interesting. >>> >>> It's obviously wrong to focus too heavily on any test set, but I've >>> bundled together the five images I'm currently testing with, in their >>> optimal PNG forms, and uploaded to >>> http://members.allegro.cc/ThomasHarte/temp/SamTestScreens.zip >>> >>> You should get files screen1 to screen5 (two from Dizzy, three from >>> Flashback) which as PNGs are sized 5,553, 6,108, 10,643, 10,005 and >>> 11,533 bytes respectively. >>> >>> The only thing implicit in my output data is that the images are 256 >>> pixels wide. Not all are 192 pixels high but the height is left >>> implicit from the total number of pixels. Palettes are included with >>> the images. >>> >>> With that in mind, I'm currently at 5,531, 7,273, 11,956, 10,538 and >>> 12,367 bytes. But still working on it. So I won't take offence if you >>> embarrass me thoroughly... >>> >>> On Thu, Jul 29, 2010 at 4:18 PM, Adrian Brown >>> wrote: >>>> I hope these will support the EEPROM highscore saving or similar ;). Ive >>>> got some strange compression modes, bung me the image and ill see how well >>>> i can compress it. Good to see people looking at the Sam again. Im >>>> hoping to get some more time on Sam Uip soon >>>> >>>> Adrian >>>> >>>> -Original Message- >>>> From: owner-sam-us...@nvg.ntnu.no [
Re: Dizzy (was:Porting spectrum games...)
Sadly I'm already doing that and still doing a lot worse than you. At this point I'd definitely suggest that if you're willing to donate code then it be used over anything I can come up with. I'm still trying though! On Sat, Jul 31, 2010 at 1:23 PM, Adrian Brown wrote: > Oh one thing ive found out that may help in your tests. Dont compress > the data as nibble pairs. If you convert the data into bytes (only > using values 0 - 15) then compress that. (obviously in the decompressor > you need to patch it back so two bytes become one nibble). You may find > you get a much better compression rate. > > Adrian > > -Original Message- > From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] > On Behalf Of Adrian Brown > Sent: 31 July 2010 13:16 > To: sam-users@nvg.ntnu.no > Subject: RE: Dizzy (was:Porting spectrum games...) > > Ok, providing I havent made any mistakes on the compressor it looks like > the sizes are down at: > > 1: 256 x 141 : 4416 > 2: 256 x 141 : 5613 > 3: 256 x 192 : 9103 > 4: 256 x 192 : 8594 > 5: 256 x 192 : 10103 > > Ill write the decompressor and check, depends how slow it is to > decompress i guess ;) > > > > >
Re: Dizzy (was:Porting spectrum games...)
Oh, but for the record, with what I think is a completely straight reimplementation of PNG that isn't particularly intelligent in searching for the smallest size: 1: 256 x 141 : 5190 (774 bytes worse than you) 2: 256 x 141 : 6439 (826 bytes worse) 3: 256 x 192 : 10041 (938 bytes worse) 4: 256 x 192 : 9326 (732 bytes worse) 5: 256 x 192 : 10599 (496 bytes worse) Which puts me, on average, about 10% worse than you. On Sat, Jul 31, 2010 at 1:33 PM, Thomas Harte wrote: > Sadly I'm already doing that and still doing a lot worse than you. At > this point I'd definitely suggest that if you're willing to donate > code then it be used over anything I can come up with. > > I'm still trying though! > > On Sat, Jul 31, 2010 at 1:23 PM, Adrian Brown > wrote: >> Oh one thing ive found out that may help in your tests. Dont compress >> the data as nibble pairs. If you convert the data into bytes (only >> using values 0 - 15) then compress that. (obviously in the decompressor >> you need to patch it back so two bytes become one nibble). You may find >> you get a much better compression rate. >> >> Adrian >> >> -Original Message- >> From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] >> On Behalf Of Adrian Brown >> Sent: 31 July 2010 13:16 >> To: sam-users@nvg.ntnu.no >> Subject: RE: Dizzy (was:Porting spectrum games...) >> >> Ok, providing I havent made any mistakes on the compressor it looks like >> the sizes are down at: >> >> 1: 256 x 141 : 4416 >> 2: 256 x 141 : 5613 >> 3: 256 x 192 : 9103 >> 4: 256 x 192 : 8594 >> 5: 256 x 192 : 10103 >> >> Ill write the decompressor and check, depends how slow it is to >> decompress i guess ;) >> >> >> >> >> >
Re: Dizzy (was:Porting spectrum games...)
Oh, but wait! Enabling searching for the best LZ77 window and pattern size (just in terms of 4 bits, 8 bits, 12 bits or 16 bits — not a completely free search) seems to put me at: 1: 256 x 141 : 4593 2: 256 x 141 : 5731 3: 256 x 192 : 8520 4: 256 x 192 : 8267 5: 256 x 192 : 9440 Currently a little worse than you for the Dizzys, a little better for the Flashbacks. I'm going to see if there's anything to gain from variable length LZ77 regions (at the minute it picks the predictor per line by trying every predictor with every combination of LZ77 length, then bundles together all the best predictors into a big block and LZ77s the whole lot, finding the best window/pattern size afresh for the whole lot). I guess I can look for patterns in the results of the line-by-line search. On Sat, Jul 31, 2010 at 2:04 PM, Thomas Harte wrote: > Oh, but for the record, with what I think is a completely straight > reimplementation of PNG that isn't particularly intelligent in > searching for the smallest size: > > 1: 256 x 141 : 5190 (774 bytes worse than you) > 2: 256 x 141 : 6439 (826 bytes worse) > 3: 256 x 192 : 10041 (938 bytes worse) > 4: 256 x 192 : 9326 (732 bytes worse) > 5: 256 x 192 : 10599 (496 bytes worse) > > Which puts me, on average, about 10% worse than you. > > On Sat, Jul 31, 2010 at 1:33 PM, Thomas Harte > wrote: >> Sadly I'm already doing that and still doing a lot worse than you. At >> this point I'd definitely suggest that if you're willing to donate >> code then it be used over anything I can come up with. >> >> I'm still trying though! >> >> On Sat, Jul 31, 2010 at 1:23 PM, Adrian Brown >> wrote: >>> Oh one thing ive found out that may help in your tests. Dont compress >>> the data as nibble pairs. If you convert the data into bytes (only >>> using values 0 - 15) then compress that. (obviously in the decompressor >>> you need to patch it back so two bytes become one nibble). You may find >>> you get a much better compression rate. >>> >>> Adrian >>> >>> -Original Message- >>> From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] >>> On Behalf Of Adrian Brown >>> Sent: 31 July 2010 13:16 >>> To: sam-users@nvg.ntnu.no >>> Subject: RE: Dizzy (was:Porting spectrum games...) >>> >>> Ok, providing I havent made any mistakes on the compressor it looks like >>> the sizes are down at: >>> >>> 1: 256 x 141 : 4416 >>> 2: 256 x 141 : 5613 >>> 3: 256 x 192 : 9103 >>> 4: 256 x 192 : 8594 >>> 5: 256 x 192 : 10103 >>> >>> Ill write the decompressor and check, depends how slow it is to >>> decompress i guess ;) >>> >>> >>> >>> >>> >> >
Re: Dizzy (was:Porting spectrum games...)
Could it be the simple fact that I'm sorting the palette by hue to try to make the numeric predictor more likely to be helpful? Ordering obviously makes a difference, but there isn't time to try all of the 16! possibilities so that's my current guess. Another way through might be to build some sort of graph that awards each palette colour a distance from the other colours depending on the probability of it falling next to them in the image, then to arrange the palette so that colours that are more likely to be nearby in the image are more likely to be nearby in the palette. On Sat, Jul 31, 2010 at 3:01 PM, Adrian Brown wrote: > Yer - yours is probably a little better then, the flashback screens are more > what you want to look at. Ill play around a little more. > > Adrian > > -Original Message- > From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On > Behalf Of Thomas Harte > Sent: 31 July 2010 14:31 > To: sam-users@nvg.ntnu.no > Subject: Re: Dizzy (was:Porting spectrum games...) > > Oh, but wait! Enabling searching for the best LZ77 window and pattern > size (just in terms of 4 bits, 8 bits, 12 bits or 16 bits - not a > completely free search) seems to put me at: > > 1: 256 x 141 : 4593 > 2: 256 x 141 : 5731 > 3: 256 x 192 : 8520 > 4: 256 x 192 : 8267 > 5: 256 x 192 : 9440 > > Currently a little worse than you for the Dizzys, a little better for > the Flashbacks. I'm going to see if there's anything to gain from > variable length LZ77 regions (at the minute it picks the predictor per > line by trying every predictor with every combination of LZ77 length, > then bundles together all the best predictors into a big block and > LZ77s the whole lot, finding the best window/pattern size afresh for > the whole lot). I guess I can look for patterns in the results of the > line-by-line search. > > On Sat, Jul 31, 2010 at 2:04 PM, Thomas Harte > wrote: >> Oh, but for the record, with what I think is a completely straight >> reimplementation of PNG that isn't particularly intelligent in >> searching for the smallest size: >> >> 1: 256 x 141 : 5190 (774 bytes worse than you) >> 2: 256 x 141 : 6439 (826 bytes worse) >> 3: 256 x 192 : 10041 (938 bytes worse) >> 4: 256 x 192 : 9326 (732 bytes worse) >> 5: 256 x 192 : 10599 (496 bytes worse) >> >> Which puts me, on average, about 10% worse than you. >> >> On Sat, Jul 31, 2010 at 1:33 PM, Thomas Harte >> wrote: >>> Sadly I'm already doing that and still doing a lot worse than you. At >>> this point I'd definitely suggest that if you're willing to donate >>> code then it be used over anything I can come up with. >>> >>> I'm still trying though! >>> >>> On Sat, Jul 31, 2010 at 1:23 PM, Adrian Brown >>> wrote: >>>> Oh one thing ive found out that may help in your tests. Dont compress >>>> the data as nibble pairs. If you convert the data into bytes (only >>>> using values 0 - 15) then compress that. (obviously in the decompressor >>>> you need to patch it back so two bytes become one nibble). You may find >>>> you get a much better compression rate. >>>> >>>> Adrian >>>> >>>> -Original Message- >>>> From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] >>>> On Behalf Of Adrian Brown >>>> Sent: 31 July 2010 13:16 >>>> To: sam-users@nvg.ntnu.no >>>> Subject: RE: Dizzy (was:Porting spectrum games...) >>>> >>>> Ok, providing I havent made any mistakes on the compressor it looks like >>>> the sizes are down at: >>>> >>>> 1: 256 x 141 : 4416 >>>> 2: 256 x 141 : 5613 >>>> 3: 256 x 192 : 9103 >>>> 4: 256 x 192 : 8594 >>>> 5: 256 x 192 : 10103 >>>> >>>> Ill write the decompressor and check, depends how slow it is to >>>> decompress i guess ;) >>>> >>>> >>>> >>>> >>>> >>> >> > > > >
Re: Dizzy (was:Porting spectrum games...)
As a quick mea culpa, there was a bug in my code that means the second set of figures I had were wrong. I'm back to an average 10% and up to 15% worse than Adrian. On Sun, Aug 1, 2010 at 9:37 AM, Frode Tennebø wrote: > On Sun, 01 Aug 2010 10:18:55 +0200, Andrew Park wrote: > >> Back in the days of the Sam there was a screen compressing utility which >> was ok, anyone know where i can find it? > > Lord Insanity's Screen Cruncher > (ftp://ftp.nvg.ntnu.no/pub/sam-coupe/disks/utils/LordInsanityScreenCruncher.zip)? > > -Frode > > -- > ^ Frode Tennebø | email: fr...@tennebo.com | fr...@irc ^ > | with Standard.Disclaimer; use Standard.Disclaimer; | >
Re: Dizzy (was:Porting spectrum games...)
It'll be interesting to see how you've done it. If code overhead is an issue then you've obviously taken quite a different approach to me. I had a quick poke around on Amazon for textbooks on this sort of thing but ended up preordering a Kindle. So that's my book budget gone for the next couple of months... On Sun, Aug 1, 2010 at 1:46 PM, Adrian Brown wrote: > Ill extract it from the code that I cant send and put it in its own project > is C first > > Adrian > > -Original Message- > From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On > Behalf Of Stefan Drissen > Sent: 01 August 2010 13:31 > To: sam-users@nvg.ntnu.no > Subject: RE: Dizzy (was:Porting spectrum games...) > > Not a C person, but would http://sdcc.sourceforge.net/ help? > > -Original Message- > From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On > Behalf Of Adrian Brown > Sent: zondag 1 augustus 2010 14:04 > To: sam-users@nvg.ntnu.no > Subject: RE: Dizzy (was:Porting spectrum games...) > > This will be a nightmare to get into z80 ;) that is the downside. (unless > you build it using Sam C - it might compile under that) but i think a z80 > version would be required. > > -Original Message----- > From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On > Behalf Of Thomas Harte > Sent: 01 August 2010 12:16 > To: sam-users@nvg.ntnu.no > Subject: Re: Dizzy (was:Porting spectrum games...) > > As a quick mea culpa, there was a bug in my code that means the second > set of figures I had were wrong. I'm back to an average 10% and up to > 15% worse than Adrian. > > On Sun, Aug 1, 2010 at 9:37 AM, Frode Tennebø wrote: >> On Sun, 01 Aug 2010 10:18:55 +0200, Andrew Park > wrote: >> >>> Back in the days of the Sam there was a screen compressing utility which >>> was ok, anyone know where i can find it? >> >> Lord Insanity's Screen Cruncher >> > (ftp://ftp.nvg.ntnu.no/pub/sam-coupe/disks/utils/LordInsanityScreenCruncher. > zip)? >> >> -Frode >> >> -- >> ^ Frode Tennebø | email: fr...@tennebo.com | fr...@irc ^ >> | with Standard.Disclaimer; use Standard.Disclaimer; | >> > > > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.851 / Virus Database: 271.1.1/3042 - Release Date: 07/31/10 > 20:34:00 > > > > >
Re: Dizzy (was:Porting spectrum games...)
I've just been reading about range/arithmetic coding, which feels like it should do better than Huffman but seems to require some modulo arithmetic per input or output token so may not be time effective on a Sam. Have you been using anything like that? On Mon, Aug 2, 2010 at 12:43 PM, Thomas Harte wrote: > It'll be interesting to see how you've done it. If code overhead is an > issue then you've obviously taken quite a different approach to me. > > I had a quick poke around on Amazon for textbooks on this sort of > thing but ended up preordering a Kindle. So that's my book budget gone > for the next couple of months... > > On Sun, Aug 1, 2010 at 1:46 PM, Adrian Brown > wrote: >> Ill extract it from the code that I cant send and put it in its own project >> is C first >> >> Adrian >> >> -Original Message- >> From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On >> Behalf Of Stefan Drissen >> Sent: 01 August 2010 13:31 >> To: sam-users@nvg.ntnu.no >> Subject: RE: Dizzy (was:Porting spectrum games...) >> >> Not a C person, but would http://sdcc.sourceforge.net/ help? >> >> -Original Message- >> From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On >> Behalf Of Adrian Brown >> Sent: zondag 1 augustus 2010 14:04 >> To: sam-users@nvg.ntnu.no >> Subject: RE: Dizzy (was:Porting spectrum games...) >> >> This will be a nightmare to get into z80 ;) that is the downside. (unless >> you build it using Sam C - it might compile under that) but i think a z80 >> version would be required. >> >> -Original Message- >> From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On >> Behalf Of Thomas Harte >> Sent: 01 August 2010 12:16 >> To: sam-users@nvg.ntnu.no >> Subject: Re: Dizzy (was:Porting spectrum games...) >> >> As a quick mea culpa, there was a bug in my code that means the second >> set of figures I had were wrong. I'm back to an average 10% and up to >> 15% worse than Adrian. >> >> On Sun, Aug 1, 2010 at 9:37 AM, Frode Tennebø wrote: >>> On Sun, 01 Aug 2010 10:18:55 +0200, Andrew Park >> wrote: >>> >>>> Back in the days of the Sam there was a screen compressing utility which >>>> was ok, anyone know where i can find it? >>> >>> Lord Insanity's Screen Cruncher >>> >> (ftp://ftp.nvg.ntnu.no/pub/sam-coupe/disks/utils/LordInsanityScreenCruncher. >> zip)? >>> >>> -Frode >>> >>> -- >>> ^ Frode Tennebø | email: fr...@tennebo.com | fr...@irc ^ >>> | with Standard.Disclaimer; use Standard.Disclaimer; | >>> >> >> >> >> >> No virus found in this incoming message. >> Checked by AVG - www.avg.com >> Version: 9.0.851 / Virus Database: 271.1.1/3042 - Release Date: 07/31/10 >> 20:34:00 >> >> >> >> >> >
Re: Dizzy (was:Porting spectrum games...)
LZMA doesn't seem to be terribly well documented, but I'm curious so do you mind if I ask a few questions? The LZ77-style stuff is quite well documented on Wikipedia, with variable packet sizes but otherwise unremarkable. Though it looks like length of repetitions is limited to 273 at most and the maximum distance isn't particularly clear. I guess for Sam screen purposes, 273 is more than enough and 15 bits for distance is always more than enough, with fewer bits being an option? Then there's the range coding aspect. It looks like the individual LZ77 packets are range coded and the fixed values encoded in literal packets are range coded separately? So you end up with two streams and you follow the LZ77 stream, grabbing a decoded digit from the data stream whenever you hit a literal packet? There are vague references to context and Markov chains without much exposition — I've taken this to mean that you've not just one table of symbol probabilities, but you divide them into groups and each group uses a separate table of probabilities recording what may come next. Those probabilities are then used for the range coding. And it's implied that group membership is indicated by the value of a certain number of the most significant bits in the normal LZMA course of things, presumably to make the probability tables cheap to transmit. Is that all correct? Or even close? It's all much more clever than anything I was trying. On Tue, Aug 3, 2010 at 9:11 PM, Adrian Brown wrote: > Im using an LZMA approach similar to that in 7-zip - ive nearly finished > moving the code out of my project stuff so i can send it over. > > Adrian > > -Original Message- > From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On > Behalf Of Thomas Harte > Sent: 03 August 2010 18:16 > To: sam-users@nvg.ntnu.no > Subject: Re: Dizzy (was:Porting spectrum games...) > > I've just been reading about range/arithmetic coding, which feels like > it should do better than Huffman but seems to require some modulo > arithmetic per input or output token so may not be time effective on a > Sam. Have you been using anything like that? > > On Mon, Aug 2, 2010 at 12:43 PM, Thomas Harte > wrote: >> It'll be interesting to see how you've done it. If code overhead is an >> issue then you've obviously taken quite a different approach to me. >> >> I had a quick poke around on Amazon for textbooks on this sort of >> thing but ended up preordering a Kindle. So that's my book budget gone >> for the next couple of months... >> >> On Sun, Aug 1, 2010 at 1:46 PM, Adrian Brown >> wrote: >>> Ill extract it from the code that I cant send and put it in its own project >>> is C first >>> >>> Adrian >>> >>> -Original Message- >>> From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On >>> Behalf Of Stefan Drissen >>> Sent: 01 August 2010 13:31 >>> To: sam-users@nvg.ntnu.no >>> Subject: RE: Dizzy (was:Porting spectrum games...) >>> >>> Not a C person, but would http://sdcc.sourceforge.net/ help? >>> >>> -Original Message- >>> From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On >>> Behalf Of Adrian Brown >>> Sent: zondag 1 augustus 2010 14:04 >>> To: sam-users@nvg.ntnu.no >>> Subject: RE: Dizzy (was:Porting spectrum games...) >>> >>> This will be a nightmare to get into z80 ;) that is the downside. (unless >>> you build it using Sam C - it might compile under that) but i think a z80 >>> version would be required. >>> >>> -Original Message- >>> From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On >>> Behalf Of Thomas Harte >>> Sent: 01 August 2010 12:16 >>> To: sam-users@nvg.ntnu.no >>> Subject: Re: Dizzy (was:Porting spectrum games...) >>> >>> As a quick mea culpa, there was a bug in my code that means the second >>> set of figures I had were wrong. I'm back to an average 10% and up to >>> 15% worse than Adrian. >>> >>> On Sun, Aug 1, 2010 at 9:37 AM, Frode Tennebø wrote: >>>> On Sun, 01 Aug 2010 10:18:55 +0200, Andrew Park >>> wrote: >>>> >>>>> Back in the days of the Sam there was a screen compressing utility which >>>>> was ok, anyone know where i can find it? >>>> >>>> Lord Insanity's Screen Cruncher >>>> >>> (ftp://ftp.nvg.ntnu.no/pub/sam-coupe/disks/utils/LordInsanityScreenCruncher. >>> zip)? >>>> >>>> -Frode >>>> >>>> -- >>>> ^ Frode Tennebø | email: fr...@tennebo.com | fr...@irc ^ >>>> | with Standard.Disclaimer; use Standard.Disclaimer; | >>>> >>> >>> >>> >>> >>> No virus found in this incoming message. >>> Checked by AVG - www.avg.com >>> Version: 9.0.851 / Virus Database: 271.1.1/3042 - Release Date: 07/31/10 >>> 20:34:00 >>> >>> >>> >>> >>> >> > > > >
Cables for a composite PAL monitor?
As someone who doesn't care enough about TVs to do anything but accept hand-me-downs and other bits of charity, I've just received an old plasma from work. But the catch is that it's a decade old and is better described as a monitor than a TV, built for the international market. So, in addition to VGA and DVI, it has composite and component inputs and can accept a PAL or NTSC signal but has no tuner and no SCART socket. It has an S-Video socket, a bunch of phonos and those other things that I don't know the name of, but look like a bit like phonos except that they stick out further and seem to have a smaller hole. They're for component input; it's a normal yellow phono for composite. Lacking another connector, I assume it's sync-on-green. Obviously the SAM can output RGB and composite from its not-quite-SCART socket, but what can I do to connect it to my TV? Quazar doesn't seem to have anything relevant in stock and I'm a soldering dunce.
Re: Cables for a composite PAL monitor?
Yes - lots of those, including two next to the composite video. The screen is comically oversized if anything, and they seem to have taken the opportunity to really cover the thing with inputs... Probably best to get in touch privately and sort this out. I'm finally about to scramble desperately onto the housing ladder, so depending on timings I may even have a new address to report. On Monday, April 18, 2011, Colin Piggot wrote: > Thomas wrote: > > it's a normal yellow phono for composite. > > Obviously the SAM can output RGB and composite from its > not-quite-SCART socket, but what can I do to connect it to my TV? > Quazar doesn't seem to have anything relevant in stock and I'm a > soldering dunce. > > > But I do make up customised cables on request :) > > I can build a cable to connect from the SAM SCART socket to a phono plug for > your TV's Composite Video input. Also, I assume there is red and white phono > sockets for audio input too? > > Colin > = > Quazar : Hardware, Software, Spares and Repairs for the SAM Coupé > 1995-2011 - Celebrating 17 Years of developing for the SAM Coupé > Website: http://www.samcoupe.com/ >
Re: Contention and JR instruction timing.
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). 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. Standard comments about hindsight apply, of course. On Tue, Apr 26, 2011 at 12:46 PM, Geoff Winkless wrote: > 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.
> 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 Well, no, that's why I costed for doing the full screen twice in two frames — a read and a write, plus some useful CPU time (even after drawing a new row or column of pixels so that it's a scroll), at 25fps. Though I think your main point is correct; if graphics ability were the main objective then you'd be looking at a quite different route, not a bunch of little tweaks or minor additions. And we're told that a selectable screen start address was considered but not possible in the current design, so the real question is what else do you jettison and how do you do it within the constraints beyond mere final manufacturing cost. It's an interesting thought experiment, but it is predicated on one particular aspect being elevated in importance in such a way as to violate the original design goals. Vaguely related: has anybody here ever played with one of those FPGAs?
Re: Contention and JR instruction timing.
On Tue, Apr 26, 2011 at 4:58 PM, Chris Pile wrote: > Besides, there's something *pure* about having a chunk of RAM and a CPU - > and not much else! While it's pure, and the basis for some of the great machines — the Spectrum, obviously, but also the ST, sort of the VGA-era PC and the original Mac (with an extra end-of-scanline byte fetch pushed to a speaker, to give ~2Hz sampled sound output for almost free!) — I get a similar kick out of the modern, programmable GPUs. Though I guess they largely compartmentalise the RAM + [heavily parallel] processor bit and leave the rest of the system to whatever it likes. I think I'm becoming a big fan of parallel programming in general. I'm very glad I did some LISP stuff at university; not sure how I'd take to it if I was coming over from the purely procedural world.
Re: Sam Coupe Testing
Sorry, I don't know most of the answers and am probably not about to be entirely helpful but since there don't seem to have been any other answers... > I have replaced the TV lead from inside the power unit, and I get a picture on > my TV. > > However, if the TV is tuned in properly - I get a black and white picture, > otherwise the start up screen is very blue. So there's no way to get colour at all (other than a whole-screen tint)? I remember there being some sort of hardware fault that can cause that — it happened to my original Sam Coupe and we ended up sending it back under the warranty. I think they must just have shipped a new unit, since I remember the disk light changed colour too. That said, it's very that's a completely unrelated story. > There were two SCART leads with the computer, but neither seem to give an > output. > > I seem to recall reading that the SCART is very different to normal. > > Does anyone have spare SCART and cassette leads please? Colin can generally sell you those things if that's acceptable — his website is http://samcoupe.com/ and both composite and RGB scart leads are £9.99. > Also - I have found a semi-circular rubber foot - I presume that the Sam > should > have four of these in the holes on the side of the casing? > > Does anyone have some spares? Yep, should have four, usually blue but sometimes black. I've no ideas about spares. > My Sam has 512K memory, with piggy-backed RAM chips and a wire which runs > across > and is connected to one of the pins on the internal expansion port (to the > right > of the disk drive). > > Is this normal - as it seems an awkward way of connecting it! No, that's probably some sort of do-it-yourself modification. I've never actually fitted one, but I think the official upgrade is just a tiny daughterboard that you plug in after unscrewing the little panel with copyright information/etc on the bottom to reveal the relevant hole. > Finally, I have an MGT mouse interface for the Sam, and a Comms interface - > what > is the best way of testing these? The mouse interface expects an Atari ST-style serial mouse, so you'll need to get hold of one of those. It came with a demo disk including a mouse-driven version of Flash! and some code to access the mouse from your own BASIC programs. It's not the same thing but you can get the 'Mouse Driver 2.0' disk from http://www.worldofsam.org/node/214 legally, as distribution rights have been granted. A bunch of PD software that supports it is also available. As for the comms interface, I've no ideas specific enough to be helpful.
Re: Accessing Sam formatted disks through a USB floppy drive
On OS X, which of course has a BSD-derived layer, I wasn't able to get anything using dd — my USB floppy drive showed up as a block device and exposed only the PC-style double density sectors as blocks. I was able successfully to image any disk that didn't use any of its tenth-per-track sectors, but that's the full extent of it. The Kyroflux, at about £80, doesn't actually look like a bad deal, but can I attach a Disciple/+D drive to it? It looks to be the same sort of connector, and to match the one I had on my Acorn Electron +3 (equivalent) cartridge, but is it? On Fri, Jul 22, 2011 at 9:54 AM, nev young wrote: > On 22/07/11 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? >> > Very little hope of doing that. > > All the programs I've seen, or written myself, need to access the floppy > disk controller which you usually can not do through usb. > > If your PC has a floppy controller I would suggest connecting a floppy drive > directly to that, (possibly hanging out of the side and balanced on a pile > of books) to do the copy. Then put your machine back together again. > > If you really want to use the usb floppy drive then if you're feeling very > strong hearted you might try running a linux system and using the dd > utility. Something like: > dd noerror if=/dev/fda of=~/image.txt > > Tell it to ignore errors, as on a 1.44Mb disk it will expect 18** sectors > per track. So the last 8 will error. I've never tried this so can not vouch > for if it would work. Even if it does you'll have to play about with the > image to make it usable. > > > ** I think a 1.44Mb disk has 2 sides of 80 tracks with 18 sectors of 512 > bytes but I may be wrong. > > Nev >
Re: Sam Hardware / Software for sale and some disks free
I've wanted to see DRiVER for a while, having read the first three Inside Macintoshes a few years ago and the Smalltalk-80 book a little before that. It'd be interesting to play about with. But how does sellmyretro work? I notice the items listed as bids rather than purchases aren't also on eBay, so it presumably has its own auction system? The entire selfish question I'm building up to is: I'm not in the UK right now, and won't be for a bit more than a week after the auctions end; would you be so willing and is sellmyretro set up so that, if I were to win any, I could ask you not to post my items for a week? On Fri, Aug 26, 2011 at 2:23 AM, Rich Mellor wrote: > Good evening, > > I have listed a few bits of SAM hardware and software on sellmyretro.com - > > http://www.sellmyretro.com/category/All+categories/Retro+Computers/SAM+Coup%C3%A9 > > I also have 7 SAM formatted floppies free to a good home (for the cost of > postage) - they have various hand written labels on them, including > Electronic Calculations, Games, Eyeconiac + Z8 Demo (I think!), Graphics, > and Hacker Text. > > If anyone wants them to have a mooch through, let me know before they go in > the bin! > > -- > Rich Mellor > RWAP Services > > http://www.rwapsoftware.co.uk > http://www.rwapservices.co.uk > > -- Try out our new site: http://sellmyretro.com > > >
Resistor R55
My SAM has an intermittent fault involving the 'bright' palette bit having no effect. In reality it seems to be so intermittent now that I'm not sure I still have a problem but nevertheless I thought I'd open the case and clean out any dust, etc, since even my very low level of electrical competence leaves me aware that intermittent faults can be related to heat and the accumulation of dust creates heat problems. I know the SAM doesn't have any fans to collect dust and operates at a very low temperature but since it doesn't take a lot of effort to check I thought I'd have a glance. It looks like a previous owner of my current SAM has had occasion to replace resistor R55, or at least, to solder an additional copy of R55 on top of the existing one. See http://postimage.org/image/1g4kbz490/ Immediate follow-on questions, mostly resulting from me being an electrical dunce, are: what does R55 do, what would be the likely effect if it was a bit dodgy and is it really okay just to solder an extra resistor on top of an existing one?
Re: Resistor R55
I hadn't considered that bright might be variable by channel — I'll
have to check that out.
If it were MC1377P affecting all channels then presumably I'd see the
effect only through the aerial or a single-line video output? If I
were to find a suitable RGB scart cable then I'd still get the
expected output?
Re: the ASIC and primarily because I'm curious, how would making a
replacement for that work? Are there readily available FPGAs that
could drop straight into the same slot, if not then how expensive is
it to build some sort of bridge? As I said, I'm quite an electrical
dunce so don't hesitate to be patronising.
Given that at least some of my bright comes and goes, my floppy drive
seems to be dead (it makes a spinning noise and lights up but fails to
report that a disk is inserted) and there's a real chance I may
emigrate soon it might be time for me to put my real SAM away for
good. That'd be a little sad.
On Tue, Oct 4, 2011 at 10:11 AM, Leszek Chmielewski wrote:
>
>
> 2011/10/4 nev young
>>
>> On 03/10/11 23:40, Andrew Collier wrote:
>>>
>>> On 3 Oct 2011, at 16:22, Thomas Harte wrote:
>>>
>>>> It looks like a previous owner of my current SAM has had occasion
>>>> to replace resistor R55, or at least, to solder an additional copy
>>>> of R55 on top of the existing one. See
>>>> http://postimage.org/image/1g4kbz490/
>>>>
>>>> Immediate follow-on questions, mostly resulting from me being an
>>>> electrical dunce, are: what does R55 do, what would be the likely
>>>> effect if it was a bit dodgy and is it really okay just to solder
>>>> an extra resistor on top of an existing one?
>>>
>>> According to the schematics in the tech manual, R55 is doing
>>> something to do with the MIC tape interface, and should be a 100kΩ
>>> resistor - which if I'm reading the photo correctly (the colour bands
>>> look {brown, black, yellow, gold}) is exactly what it is.
>>>
>>> Two of them wired in parallel are equivalent to a single resistor of
>>> 50kΩ (assuming they both work) though I'm not certain what the
>>> implication of that is for the rest of the circuit.
>>>
>> R55 and C28 form a feedback circuit that should "square up" the audio
>> signal coming from the tape cassette. Reducing R55 from 100K to 50K, by
>> putting two in parallel, will increase the amount of feedback.
>>
>> The Bright signal is generated by the ASIC and appears on pin 18 (If I
>> read my diagram correctly). It then goes to R65, R69 and R73 (all 36K
>> [orange, blue, orange stripes]) to drive each of the colour driver
>> transistors M3(green), M4(red) and M5(blue) (3x BC547).
>>
>> If you have lost bright on one colour look at the corresponding resistor
>> and PCB connections. If the transistor has blown you would lose that
>> colour completely. If you have no bright on any colour then check the
>> output of the ASIC and the PCB connections from there to the 3 resistors
>> for cracks, dry joints, broken through plating etc.
>>
>> If there is no signal coming out of the ASIC then get used to a dull
>> life. :-(
>>
>> Nev
>>
> My SAM has no BRIGHT too. There was a shortcut between Composite and +12V,
> so the MC1377P was burned out (Just got a replacement by desoldering a Atari
> Mega STE), I lost BRIGHT too as the ASIC was toasted a little too. After
> replacing it with ASIC from my spare SAM the BRIGHT is back again.
> It is time to design a replacement ASIC. Velesoft is working on one since
> years, but he is too ambitious: 4096 Colours, Hardware sprites and
> scrolling...
> LCD
Re: SimCoupe Speed
I think I'm right to say that external RAM can be paged into the top 32kb of address space. And it's presumably uncontended? So you could page some in and run a 48 emulator but everything would run at quite the wrong speed. Simon: I've always found 2048 samples to be the sort of level where most operating systems start playing nice with audio output; assuming 44100Hz output, wouldn't synchronising to that limit you to only about 22 synchronisation points a second? So frames would end up bunched together? Not really on topic, I admit, and the evidence that you know what you're doing is plentiful. I'm just curious. On Tue, Oct 25, 2011 at 12:38 PM, Roger Jowett wrote: > key repeats? > > is it impossible to run 48 emulator snapshots in external ram? > > On 24 October 2011 14:35, Simon Owen wrote: >> Hi Ian, >> >> I'm hoping fixed running rates will come 'for free' as part of the switch to >> audio-based synchronisation (rather than the current timer method). >> >> In the meantime, if you don't actually need the key repeats, try this >> patched ROM to disable them: http://dl.dropbox.com/u/2553707/norepeat.zip >> >> Extract it somewhere, then select it from Tools -> Options -> System (tab) >> -> ROM image. Reset the emulated machine to activate it. >> >> Cheers, >> >> Si >> >> >> On 23 Oct 2011, at 10:33, Ian Spencer wrote: >> >>> Hi Si, >>> >>> I'm sure you have been asked this hundreds of times before so I'll >>> apologise before I start but I've always used SIMCOUPE synchronised to 50Hz >>> with most programs and with others unsynchronised where the speed was >>> useful (especially with the program which I have used for years to handle >>> my bank accounts) and set the keyboard repeat rate to prevent multiple key >>> presses being produced. But the modern 3Ghz 4CPU machines I now have are >>> just so fast it's impossible to set the repeat rate low enough. They are >>> just too fast and as many programs are much more usable when the speed is >>> 200 - 500% above the standard it would be really fantastic if this was in >>> some way selectable even if at this speed the instruction timings weren't >>> very accurately scaled. >>> >>> Best wishes, >>> Ian Spencer >>> >> >> >
Re: SimCoupe Speed
Roger: I've never had an external RAM module and have never written a program that requires the storage so I'm not talking from firsthand experience. If you've tried it and encountered problems then I probably can't help. Simon: cool, sounds good. So it's just another clue (albeit quite an authoritative one, with DirectSound at least) as to correct timing rather than an absolute authority? Or maybe that's stating things too vaguely and a better description would be analogous to a clock multiplier sort of setup? The 2048/44100 comes in and you're saying 'so I'll push another frame at what I think is however-many hundredths of a second from now, another at about 1/50th of a second after that then wait for the next pulse'? Sorry for the extended off-topic questions — I'm working on some brand new emulation stuff myself, on and off, so I'm quite interested at the minute. On Tue, Oct 25, 2011 at 2:47 PM, Roger Jowett wrote: > in the bottome 32k yes where the rom&speccy screen$ are > but can the emulator explosion program be modified to do it? it > already sdetects teh external ram > > On 25 October 2011 14:02, Simon Owen wrote: >> Yes, you could certainly fill the top 32K with faster external RAM. Though >> using Spectrum-compatible mode 1 does add extra contention stripes, so >> you'll still get an extra hit on accesses in the bottom 32K. >> >> The current SDL version of SimCoupe uses 2048 samples, so it must have been >> what I found as the best behaving too! Though I've always found SDL sound >> more awkward to work with as it requests extra data as needed, rather than >> providing a method to check the level and add more. I'm expecting to use a >> mix of time stamps and buffer requests to trigger the next frame at the >> right point, which should solve the 22-syncs issue you mention. It's a lot >> easier with DirectSound as you have tighter control over the play+write >> cursors, so you automatically get sub-frame accuracy (or you certainly used >> to – I've not checked with Vista or later). >> >> I have an occasionally worked on source branch that's moving towards doing >> that, though there are a number of related complications to untangle first. >> One day... >> >> Si >> >> >> On 25 Oct 2011, at 13:18, Thomas Harte wrote: >> >>> I think I'm right to say that external RAM can be paged into the top >>> 32kb of address space. And it's presumably uncontended? So you could >>> page some in and run a 48 emulator but everything would run at quite >>> the wrong speed. >>> >>> Simon: I've always found 2048 samples to be the sort of level where >>> most operating systems start playing nice with audio output; assuming >>> 44100Hz output, wouldn't synchronising to that limit you to only about >>> 22 synchronisation points a second? So frames would end up bunched >>> together? >>> >>> Not really on topic, I admit, and the evidence that you know what >>> you're doing is plentiful. I'm just curious. >>> >>> On Tue, Oct 25, 2011 at 12:38 PM, Roger Jowett >>> wrote: >>>> key repeats? >>>> >>>> is it impossible to run 48 emulator snapshots in external ram? >>>> >>>> On 24 October 2011 14:35, Simon Owen wrote: >>>>> Hi Ian, >>>>> >>>>> I'm hoping fixed running rates will come 'for free' as part of the switch >>>>> to audio-based synchronisation (rather than the current timer method). >>>>> >>>>> In the meantime, if you don't actually need the key repeats, try this >>>>> patched ROM to disable them: http://dl.dropbox.com/u/2553707/norepeat.zip >>>>> >>>>> Extract it somewhere, then select it from Tools -> Options -> System >>>>> (tab) -> ROM image. Reset the emulated machine to activate it. >>>>> >>>>> Cheers, >>>>> >>>>> Si >>>>> >>>>> >>>>> On 23 Oct 2011, at 10:33, Ian Spencer wrote: >>>>> >>>>>> Hi Si, >>>>>> >>>>>> I'm sure you have been asked this hundreds of times before so I'll >>>>>> apologise before I start but I've always used SIMCOUPE synchronised to >>>>>> 50Hz with most programs and with others unsynchronised where the speed >>>>>> was useful (especially with the program which I have used for years to >>>>>> handle my bank accounts) and set the keyboard repeat rate to prevent >>>>>> multiple key presses being produced. But the modern 3Ghz 4CPU machines I >>>>>> now have are just so fast it's impossible to set the repeat rate low >>>>>> enough. They are just too fast and as many programs are much more usable >>>>>> when the speed is 200 - 500% above the standard it would be really >>>>>> fantastic if this was in some way selectable even if at this speed the >>>>>> instruction timings weren't very accurately scaled. >>>>>> >>>>>> Best wishes, >>>>>> Ian Spencer >>>>>> >>>>> >>>>> >>>> >> >> >
Re: Power supply circuit diagram
You should sell those; some of us are pathologically incapable of soldering but would love a quiet power supply. On 14 January 2012 09:39, Leszek Chmielewski wrote: > > No, but my PSU was very "loud" after few minutes, so I adopted a normal > +5V/2A +12V/2A PSU by soldering the SAM PSU connector to it. Works > excellent! > In the manual they state which pins are GND, +5V and +12V, so it is very > easy and modern PSU are smaller and stronger. > > LCD > > 2012/1/14 Aley Keprt >> >> >> Hi guys, does anybody have the original Sam Coupe power supply unit >> circuit diagram? >> My power supply was damaged years ago and somebody repaired it by >> replacing something inside with an old big zener diode. I just remember that >> 12V line was dead and that diode is just a random one which we were able to >> get. Then in 90's it was not easy to buy good new diodes here, but it is >> easy to buy anything on internet now. So I just need to know what was the >> original piece in the PSU and I am going to replace it back. >> Thanks in advance. >> Aley Keprt > >
Re: Floppy drive problem
MGT sold an external interface to allow connection of standard floppy drives, including those used with the Disciple and +D interfaces and pretty much every other home computer - possibly you could locate one of those? It looks like a PC drive should attach. On 19 Jan 2012, at 21:24, Aleš Keprt wrote: > I would rather sell the whole computer than to invest more money to it. > Anyone interested? > (For collectors: I still have also the original cartoon/polystyrene box. :-)) > > I do have a plenty of working PC floppy drives at home, but I think it would > be more wise to move to the compact flash instead of putting more money to > new floppy controllers. > > /--- > Aley > > -Původní zpráva- From: Colin Piggot > Sent: Thursday, January 19, 2012 10:12 PM > To: sam-users@nvg.ntnu.no > Subject: Re: Floppy drive proble > > Thomas wrote >> the original MGT SAM Coupe diskdrives are from Citizen, they are indeed a >> bit different than PC drives. One possible way is to get a replacement >> drivebelt, or buy a replacement diskdrive, both can be ordered from Quazar: >> http://www.samcoupe.com/ > > I don't have any original Citizen drives left, and no drive belts at the > moment. > > I can provide a new disk drive system based around a modern PC disk drive > and an interface board (which I can supply on it's own without a disk drive > if you already have a spare PC drive to hand) > > Colin > > = > Quazar : Hardware, Software, Spares and Repairs for the SAM Coupé > 1995-2012 - Celebrating 18 Years of developing for the SAM Coupé > Website: http://www.samcoupe.com/ >
Re: New Game - "Dave Invaders"
I'm also going to out myself as a fan — though it took me about five goes to get to the second screen! As a career non-finisher I also have to agree with Andrew's comments on seeing a project through. My only observation would be that sometimes the collectibles aren't obvious because of the nice, detailed and colourful backgrounds. Is there any way they could periodically do a little sparkle or something? And would attempting to prod you towards an open source release have any effect? On 28 January 2012 11:41, Andrew Collier wrote: > On 27 Jan 2012, at 13:49, Andrew Gillen wrote: > >> Hi folks >> >> I've finished writing my first game for the SAM. In fact it is pretty much >> the first game I've ever programmed in assembler (certainly on the SAM >> anyway) . I've tinkered with various high level languages over the years but >> have nothing to show for it. > > Nice work! I particularly like the graphics. The Sam's 16 colours can be a > bit limiting and a lot of games have very sparse backgrounds because of that, > so it's great to see yours with lots of detail and different themes. > > Most especially though, congratulations for taking a project and seeing it > through until its released. I know from experience how difficult this can be. > > Andrew
Re: New Game - "Dave Invaders"
I'm not really sure exactly where the age divide falls on this issue and I'm willing to bet none of us is classically young, but yeah! Let's either show them or allow ourselves to be shown, as applicable. I keep meaning to do some Sam work again, but getting started always feels like a huge effort — what tool chain did you use for Dave Invaders? On 29 January 2012 10:52, Andrew Gillen wrote: > Yep and show us youngsters how it is REALLY done :) > > > -- > From: "Chris Pile" > Sent: Sunday, January 29, 2012 10:48 AM > > To: > Subject: Re: New Game - "Dave Invaders" > >>> Have to send a "me too" post - really impressed. Love the graphics. >>> That's two good new SAM games in the last year (Rob's Garden Centre >>> Of The Universe game being the other one) - what's going on?! >> >> >> I agree 100%! It's quite worrying... But inspiring all the same. Maybe >> it's time for us >> "old dogs" to dust off our assemblers and get coding!! :-) >> >> Chris... > >
Re: JAM Assembler 1.13 problems?
I was too young to appreciate it at the time but I think Fred had a great series on assembly and the Sam that flowed into the sort of topics specifically of interest to game writers. Has anyone converted those to a modern document format? Other than that I can tell you that z80 questions tend to get answered very quickly and in a good amount of detail on StackOverflow though one appears only once every other month or so, so it's not much of a learning resource. On 1 Feb 2012, at 10:39, war...@wdlee.co.uk wrote: > On a related but slightly different note... Sometime in the near future, I > want to get back into a fairly major SAM gaming project I was working on. I'm > going to give JAM a go (Just quickly tested it on my machine running Windows > 7, and seemks to work fine!). :-) I made the mistake of working in > GamesMaster again when I started it last year, but I hit a bit of an annoying > brick wall with it (Yes, I know... but it worked so well for my first few > games! :-D ) Unfortunately those limitations AREN'T because of the > limitations of the SAM, so I don't want to compromise the game from what it > could do, simply because of GamesMaster. > > So my plan is to re-program it in Assembly. And my question is... (I think I > may have asked this before, but for the life of me I can't remember, so sorry > if I have!) what's the best resource for learning it?? ;-) > > Dave, I love what you've done with "Dave Invaders" :-D What did you read for > learning how to program it? > > Quoting Balor Price : > >> Ah. I am a moron. Updated from Java 6 update 21 to update 30 and the >> problem went away. >> >> Must say, though, I would never have expected that to have been a problem, >> especially because your binaries are all JAR files instead of JAD midlets. >> Okay I'm confused again now! >> >> Howard >> >> >> On 01-Feb-12 07:59, david brant wrote: >>> People do use it then, not had much in the way of feedback. >>> >>> Jam Assembler does not doing anything special with the font or anything >>> like that. It would be using Windows API for fonts and messages etc. i.e. >>> anything standard windows stuff. >>> >>> Jam Assembler not been tested on anything newer than XP though. >>> >>> What version of Java is your computer using? Have you tried re loading Jam >>> Assembler? I have a newer version on my computer which sorts out some >>> project view issues and does method inheritance I'll upload it tonight with >>> a bit of luck. >>> >>> Otherwise can you send me a screen shot please. >>> >>> On 1 Feb 2012, at 01:19, Balor Price wrote: >>> So, hmmm... while I'm fired up... Anyone having problems with the GUI in Jam Assembler? It's been a while since I tinkered, but now I'm getting gobbledygook instead of English in the dropdown menus and dialogue boxes... At a guess I'd say the font lookups had gone askew, it's a JAR file that's executed so it's not relying on Windows API calls or anything. David? Howard >>> >> > > >
Single pixel hardware scroll?
I thought this was worth discussing separately but in the JAM Assembler conversation earlier today Andrew Gillan provided a link to http://sam.speccy.cz/ , on which one of the documents is http://sam.speccy.cz/coding/hardware_scroll.txt — which alleges that changing the border rapidly between black and white can affect the position of the pixel area within the television frame by a row. Sadly it doesn't bother to explain what aspect of the hardware it thinks is responsible or to provide any real timing information, preferring to talk at great length about how a single pixel hardware scroll would buy you two frames to update the display rather than one if you wanted a scrolling area. It's also weirdly specific to a particular monitor in one place, and I notice that whatever effect it thinks it is relying on doesn't work in Sim Coupe. Can anyone comment on whether the article documents a real Sam hardware effect rather than merely a perceived effect specific to a particular monitor?
Re: Single pixel hardware scroll?
The weird thing then is that the article claims the effect can be triggered by border changes in the invisible part of the screen. Though I guess the screen he had probably just had a large amount of the tube hidden from the eye. The idea that border colour changes can somehow insert an extra 64us delay and an hsync does seem basically ridiculous but I thought it better to ask. At least per the spec, TVs don't have any logic for alternate frames. Whether the next is even or odd depends on whether the long sync ends in the middle of a scan line or at the end. So computers like the Sam, with a rigid sync schedule, explicitly output a non-interlaced display only. However, modern TVs - even some late model CRTs with digital sync generators - often emulate that incorrectly, and emulator authors tend to be quite parochial and superstitious about this stuff for some reason, hence e.g. the mostly invented black scan lines a lot of them like to insert. On 2 Feb 2012, at 10:24, Geoff Winkless wrote: > 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: Single pixel hardware scroll?
I'm sure I'm just repeating what you already know but... They're accurate for (most) aperture grille CRTs but completely inaccurate for shadow mask CRTs. Sony had aperture grilles patented for its Trinitron screens right up until the late 90s so they're a tiny minority, especially of televisions contemporaneous with things people commonly emulate so as to look original. You're right about the softening though in the circumstances you specify — I had in my head the emulators that chuck a huge high-contrast complete pixel wide line in between every line of real pixels, just adding yet more unrealistic contrast. I guess a proper emulation would separate luminance and chrominance, filter the two separately and the latter much more aggressively, then apply a weighted sampling that simulates a shadow mask. You could do it all on the GPU relatively easily. On 2 February 2012 11:12, Simon Owen wrote: > On 2 Feb 2012, at 10:43, Thomas Harte wrote: >> emulator authors tend to be quite parochial and superstitious about this >> stuff for some reason, hence e.g. the mostly invented black scan lines a lot >> of them like to insert. > > I find a partial scanline effect helps soften a harsh pixelated image, and > reduce the softness of the filtering done during stretching with some video > drivers. So even if they're not technically accurate I find it somehow looks > a bit more balanced than the pure image. There's probably also an aspect > that it makes it look more generated, which fits with the feel of being > emulated — so you're probably right! > > Si >
Re: Single pixel hardware scroll?
>> a) tell the difference between a normal address request and an ASIC request Is the z80's MREQ line available to peripherals? I forget whether that's active during refresh cycles but it would probably give the game away. Alternatively, the WAIT line probably gives something of the game away.
Re: Single pixel hardware scroll?
Having checked, the full complement of z80 lines are on the expansion connector so it wouldn't be a problem to figure out when the z80 is accessing memory. That being said, if the ULA fetches aren't there then there would appear to be a problem. Maybe a smarter plan would be something that plugs into the memory expansion port at the bottom? It's obviously completely feasible from a hardware point of view that you could fit a modified 256 kb expansion with some memory-mapped registers (as I can't find a pinout for that so I'm not sure if IOREQ is down there) so that, if enabled by pushing a suitably arcane initiation sequence (as per the precedent of the CPC+), you can subsequently specify a 16 or 18 bit memory offset that's added to the incoming address (overflow being lost if you go 16 bit, I guess) before that section of RAM is accessed. So you'd need to keep your program code in the internal 256 kb, and then you'd be able to use the other 256 kb for hardware scrollable screens. On 2 February 2012 12:47, Thomas Harte wrote: >>> a) tell the difference between a normal address request and an ASIC request > > Is the z80's MREQ line available to peripherals? I forget whether > that's active during refresh cycles but it would probably give the > game away. Alternatively, the WAIT line probably gives something of > the game away.
GitHub and a polygon filling routine
Quite probably not of any particular interest to most of the group since it's mostly a rehash, but because I'm about to spend quite a lot of the year country hopping I've slightly selfishly started dumping a whole bunch of my old projects onto GitHub as a kind of free backup. That means that you can now find almost exactly the same 3d engine as I released previously at http://github.com/TomHarte/Sam-Coupe-3d As set up, a build will just do exactly what the previous release did. So, amongst other things, it's still pyz80 based and should still build to the same demo as shown in http://www.youtube.com/watch?v=wTpbITdRHl0 , which anyone interested has probably already seen. Potentially of interest though, and hopefully justifying the repost, is the inclusion of my best effort to date at a solid convex polygon filler in http://github.com/TomHarte/Sam-Coupe-3d/blob/master/src/lib3d/drawpoly.z80s I'm aware there were some preliminary experiments in filled 3d on the compilation disk I released a while ago but this filler is entirely unrelated and significantly more efficient. It uses the run-slice variant of Bresenham, an edge table and an SP-facilitated span filler (so, disable interrupts temporarily unless you want occasional random pixels left on screen). It doesn't perform any pixel-level clipping so to use it in 3d proper you'd want to clip to the frustum. The code already has frustum clipping for vectors so the main issue would be avoiding repeat calculations on shared edges, though I think I eventually came to the conclusion that the smartest thing would just be a cache rather than an elaborate data structure.
Re: GitHub and a polygon filling routine
> Mine was mostly being lazy, so I don't have to managing separate source > archives for each binary release. Having thought about it, and especially comparing my stuff to yours, I think I'm also going to use the excuse of it being public but not fixed to put some serious time into cleaning and commenting. If you compare that stuff to my latest GitHub project, Clock Signal, it's a world of difference. I know programmers often wince when they look at their own old code but the thing that jumped out as really embarrassing looking back briefly after uploading was a split infinitive. Also, I always find going back and commenting to be a good way to get back into a project. I might finally managed that Freescape-style game I've always wanted to write.
Re: Emulation etc...
Per http://www.raspberrypi.org/forum/general-discussion/some-very-good-audio-news : "... you will be able to deal with two high-quality audio streams, one via HDMI and one through that jack" So it's implied there's a completely separate audio route that goes to the 3.5mm jack output, unrelated to the HDMI. My guess would be that you can't get audio out through HDMI other than through the (proprietary, closed) video decoder but you'll be able to use the jack for whatever you want. On 18 February 2012 10:23, Simon Owen wrote: > Previously I wrote: >>> It should still be possible to add a USB sound device, at the cost of >>> one USB port. Hopefully not too much extra latency either. > > I've just tested this out with my HP Microserver Linux box, which also > lacks sound hardware. I had a USB sound device that came with my > Sennheiser headset, which I don't normally use with my PC. > > I just plugged the USB widget in, fired up SimCoupe over a remote X > session and it ran fine with sound (new sound-sync code too). No > noticeable difference in latency either. > > > On 17/02/2012 20:27, da...@properbastard.co.uk wrote: >> Perhaps it's possible to emulate a simulated accelerated SAM then :) > > There will be choice of running speed, though it'll still be 6MHz from > SAM's point of view. True acceleration would break any time-critical > effects, and ASIC contention would eat much of the extra speed anyway. > > Si
Re: ASCD 0.98 WIP 1 - new version of the emulator available
I don't use Windows so was mainly going along to see if you still release source, but from here the only entry your page shows for ASCD is "ASCD 0.96 [11.09.2002] (binary: 311KB, source: 128KB)". So I'm not sure if there's a caching issue or something else at play? Also, since the Spectrum is an average of about 1500 baud (zeros and ones being different lengths, of course) I guess 33 mb would take up, ummm, about 50 hours of tape? That's 35 C90s. On 12 March 2012 18:21, Aleš Keprt wrote: > Hi Sam Coupe fans, > > I just uploaded the new version of my Sam Coupe emulator ASCD to my website. > It’s 10 years since last public release. :-D > > It is “work in progress” release. It emulates ZX Spectrum 48, 128, and Sam > Coupé. There are two or three reasons why I resurrected this old project: > > 1. It was originally meant to be “Aley’s SimCoupe for DOS” aka ASCD. But > MS-DOS is dead, so I converted whole project to Windows. I did this Windows > port back in 2003 and we used it as a ZXS emulator in game tournaments. But > there were strange bugs in Sam emulation I wasn’t able to find, so I never > released that version 0.97 to public. Now I finally found that strange main > 9 old bug. :-) > > 2. I plan to add support for Sam Coupe snapshots, QuickSave/QuickLoad > together with action replay recording. The today’s version already contains > support for QuickLoad/QuickSave, so you can play the games more easily. ;-) > But all saved ”quick” snapshots are discarded when you restart the emulator. > I need first to discuss the snapshot file format with Simon Owen to make it > usable in SimCoupe too, then I will publish the final version. > > 3. Finally, I want to add support for video recording with > QuickSave/QuickLoad. I hope some game players will record game progress of > some games to a video file. Of course it is a bit unfair to use > QuickSave/QuickLoad when making video recording, but it can help us to > compose a really “best” plays. I look forward to it. :-) > > If you are interested, download the emulator from my Downloads page: > http://www.keprt.cz/progs/ > Please let me know whether it works correctly on your computer or not. > Required configuration is simple: Windows 2000 or later, DirectX 6 or > Direct3D 9 > > --- > > I also recommend you to try this: > http://www.keprt.cz/zx_girlsaloud_something_kinda_ooh.tap.gz > It is a video file in TAP (ZX Spectrum tape file) made by Roger Jowett. > Warning: It is 33 MB long, 11 MB compressed. > You can load it in ZX Spectrum mode (use menu to insert the tape, then > switch to ZXS 128 and press Enter). I wonder how many real tape casettes > would it take to save those 33 MB of data. :-D > ASCD emulator supports TAP tapes in Sam Coupe mode too. Maybe somebody will > create similar crazy videos for Sam Coupe. The size of tapes is virtually > unlimited, so it is possible to create almost anything when you use > infinite-load speed of the emulator. > > Best regards, > Aley Keprt
Re: Dave Infuriators
Any chance of joining the GitHub gang (or any other online repository) if you've got code you're generally sharing? I've finally been motivated to start commenting my 3d stuff properly. Andrew's great work sort of makes me want to try to break out of my comfort zone and try some 2d and I'm definitely excited about Dave Infuriators. I hate to attach the word to it because of the Sam's legacy, but I really like puzzle games. On 14 March 2012 13:11, Adrian Brown wrote: > Give me a shout if you want to save from assembler. Ive got various code > that can do that using DOS hooks (no custom code as that's a pain with > SD cards etc) > > Adrian > > -Original Message- > From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] > On Behalf Of Andrew Gillen > Sent: 13 March 2012 23:31 > To: sam-users@nvg.ntnu.no > Subject: Re: Dave Infuriators > > Pleased you're all looking forward to it :) > > I'm looking to include the level editor as part of the release, though I > need to figure out how to save data to disk. It's all well and good > loading using the SAM DOS hook codes but saving I'm not so sure about. > > I have yet to tackle this, but does anyone have any tips? > > It was a miracle I managed to get this and Dave Invaders loading stuff > during runtime ! I suppose I could drop back out to basic and have the > basic listing deal with saving the block of level data out on exit from > the editor maybe, but that seems a bit ham-fisted for want of a better > term. > > -- > From: "the wub" > Sent: Thursday, March 08, 2012 8:29 PM > To: > Subject: Re: Dave Infuriators > >> This looks like great fun! The background graphics are really >> effective too, can't wait to have a go! :) >> >> Rob. > > > >
Re: Dave Infuriators
Even better — put it in a public repository and hope that somebody else cleans it up! In reality, if it fits the pattern of just about everything I've ever published then very few people will ever look at it, so what you're mainly getting is a free backup, a free inter-machine synchronisation tool and an excuse to hold yourself to a higher standard. The odd email every few years when someone stumbles upon your stuff and wants to discuss it is a bonus. On 15 March 2012 02:32, Adrian Brown wrote: > I can look at something like that, trouble is at the moment its just > collections of random source files ;) > > -Original Message- > From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On > Behalf Of Thomas Harte > Sent: 15 March 2012 02:30 > To: sam-users@nvg.ntnu.no > Subject: Re: Dave Infuriators > > Any chance of joining the GitHub gang (or any other online repository) if > you've got code you're generally sharing? > > I've finally been motivated to start commenting my 3d stuff properly. > Andrew's great work sort of makes me want to try to break out of my comfort > zone and try some 2d and I'm definitely excited about Dave Infuriators. I > hate to attach the word to it because of the Sam's legacy, but I really like > puzzle games. > > On 14 March 2012 13:11, Adrian Brown wrote: >> Give me a shout if you want to save from assembler. Ive got various >> code that can do that using DOS hooks (no custom code as that's a pain >> with SD cards etc) >> >> Adrian >> >> -Original Message- >> From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] >> On Behalf Of Andrew Gillen >> Sent: 13 March 2012 23:31 >> To: sam-users@nvg.ntnu.no >> Subject: Re: Dave Infuriators >> >> Pleased you're all looking forward to it :) >> >> I'm looking to include the level editor as part of the release, though >> I need to figure out how to save data to disk. It's all well and good >> loading using the SAM DOS hook codes but saving I'm not so sure about. >> >> I have yet to tackle this, but does anyone have any tips? >> >> It was a miracle I managed to get this and Dave Invaders loading stuff >> during runtime ! I suppose I could drop back out to basic and have the >> basic listing deal with saving the block of level data out on exit >> from the editor maybe, but that seems a bit ham-fisted for want of a >> better term. >> >> -- >> From: "the wub" >> Sent: Thursday, March 08, 2012 8:29 PM >> To: >> Subject: Re: Dave Infuriators >> >>> This looks like great fun! The background graphics are really >>> effective too, can't wait to have a go! :) >>> >>> Rob. >> >> >> >> > > >
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. > > /--- > Aley > > -Původní zpráva- From: Simon Owen > Sent: Saturday, March 24, 2012 3:10 AM > To: sam-users > Subject: SAM HAM viewer > > > Hi all, > > I've been experimenting with HAM-style tricks on SAM, to try to improve > the quality of converted images. I've aimed to modify as many colours > as possible between lines, rather than using the traditional compromise > static palette. Are there any viewers using that technique already? > > I've written a Python script to convert regular images to a new .sham > format, and a SAM viewer program to display them. > > Demo: http://simonowen.com/sam/shamview/shamview.dsk > Source code: https://github.com/simonowen/shamview > > You might recognise some of them as SAM or image processing favourites! > > It still needs work on the dynamic palette selection, which just uses > the most-frequent colours, rather than doing proper quantisation. I > left the crayons image as an example of this breaking down. > > 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: Junk mail
He did the skull animation that Aleš posted about just recently, didn't he? Which is a tape file of a 25 fps animation that a suitably accelerated emulator — such as ASCD — can play as a video. On 5 April 2012 11:52, James R Curry <8...@itdoesntsuck.com> wrote: > Or the 14 disk collection of screen captures he'd release... > > -- > James R Curry > > > On Apr 5, 2012, at 1:48 PM, Chris Pile wrote: > >> The geezer's a prize numpty! I just got hit with 30-odd "Onspeed Software >> Recommendation" >> emails and a whopping 8.29 MB email - the contents of which is anyone's >> guess! Although I >> imagine it's dozens of screen captures, as that seems a favourite of his. >> Suffice to say I didn't >> bother opening any of them - select-all/delete... Job done! >> >> Why doesn't he channel the energy he puts into spamming into doing something >> constructive >> on the SAM? Bloody hell, imagine the mega-game or ultra-utility that would >> arrive if he did! >> >> >> >> >> >> - Original Message - From: "Wayne Weedon" >> To: >> Sent: Thursday, April 05, 2012 7:13 PM >> Subject: Re: Junk mail >>> Well seems a lot of us have blocked his madness now. Hopefully he'll get >>> pissed off with not getting any attention if hardly anyone see's the crap. >>> It used to be facebook and Linkedin requests only. Got caught with his >>> pants down this time with the harvesting attempt we saw in the list! >>> Wayne...
Re: Junk mail
Well that's an email I hadn't spotted. And there's a difference between being a troll and reacting badly in an argument but I certainly wouldn't want to be Roger's defence counsel. On 6 April 2012 14:00, Wayne Weedon wrote: > On 06/04/2012 21:16, Tommo H wrote: >> >> 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. > > > He seemed to had gone off on one! > > http://blog.gmane.org/gmane.comp.systems.sam-coupe > > fascists??
Re: SAM HAM viewer
An additional observation: this might finally be an application for the Kaleidoscope? On 5 April 2012 17:10, Simon Cooke wrote: > I thought about doing something like this a while back, but as ever didn't > get chance to play with the idea. For me, the trick would have been to say > screw it and randomly/genetically generate the code required to change the > palette. On modern CPUs it shouldn't take more than a few hours to > generate/simulate even if you're brute forcing it. > > Now, of course, once you get to dithering the image and optimizing that, > you're starting to explode the solution space but it's not exactly > insurmountable. > > (I've got a 2 year old daughter and enough work to sink a battleship these > days, so unfortunately as much as I hate to say it, I think my SAM > programming days are done :'( ). > > From: Simon Owen > Sent: 4/3/2012 2:43 > > To: sam-users@nvg.ntnu.no > Subject: Re: SAM HAM viewer > > On 2 Apr 2012, at 23:58, Thomas Harte wrote: >> 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. > > That's closer the approach I was originally aiming for, but the conversion > is far more complicated. For a first attempt I restricted it to changing > the CLUT when the raster was outside the image, which still gives a > noticeable improvement over a static palette. > > My ideal approach would even eliminate steps (i) and (iii), and just use a > huge unrolled loop of OUTI instructions. That would update 1 CLUT entry per > instruction in reverse order, in a continuous loop. The converter would be > tracking a rolling window colours, with knowledge of colours no longer > needed and look-ahead to what can be set up in advance. It also needs to > understand the instruction timing, which varies across the scanline. > Thinking of implementing that still makes my head hurt! > > >> but you could instead, say, change a single palette index several >> times over the course of a single scan line, or anything in between. > > I considered individual CLUT updates for my current viewer, but it took too > much time away from the actual updating — the extra LD B,n needed costs > about the same has half an OUTI. Instead I grouped the dynamic colours > together and updated them with a small unrolled OUTI block. > > >> 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? > > Unless you need the extra resolution, I don't think there's anything to gain > from using mode 3. It uses a subset of the mode 4 CLUT, so it doesn't help > with fast access to an alternative colour set. Or am I missing something? > > Si > > >
Re: Weird caps lock behaviour
I'm not a Windows user so am unable directly to comment, but is SDL or some other cross-platform library possibly contributing to the confusion? Here in Mac world the caps lock key is a special case. It sends a key down when caps lock is engaged and a key up when caps lock is disengaged. That was originally because original Mac keyboards had a caps lock key with a little latch, like a pen with a button, so that you pressed it once and it stayed down, you pressed it again and it popped back up, and I guess it continues because Apple don't consider it sufficiently worrisome to be worth the mild breakage. Slightly boring history lesson of a minority platform aside, when last I checked SDL handled this problem by emulating Mac behaviour on all platforms. It looks like in ye olde ASCD you used Allegro. I doubt those guys had any particular strategy for handling this, and even if they did they probably got it wrong, then squabbled over maintaining DOS support ten years after the fact. So, anyway: is there any possibility that either you and other authors are seeing differing results because some are using cross-platform libraries that attempt to reconcile Mac and PC behaviour? On 8 April 2012 12:43, Aleš Keprt wrote: > Hi Sam users! > > I encountered a weird caps lock behaviour, and I'd like you to test it too > and let me know whether you encounter the same problems or not. On my > computer all emulators I tested have got problem with caps lock - it simply > doesn't work as expected. So I made changes to keyboard handling routine in > ASCD 0.98 to let it work. And now this new version is the only emulator > where caps lock works correctly on my computer, but Simon Owen wrote me that > on his computer it is different and ASCD 0.98 doesn't work correctly like > other emulators. > > Please can you test it? If you compare ASCD 0.98 with SimCoupe, you should > clearly see difference in caps lock behaviour in Sam Basic. You can also > test older ASCD 0.98 WIP which uses the old (i.e. standard) caps lock > routine and will probably be similar to SimCoupe. > > Download here: > http://www.keprt.cz/progs/ascd/ascd098.zip > http://www.keprt.cz/progs/ascd/ascd098wip3.zip > > --- > > Technical information follows: > > Normally each key sends KEYDOWN when you press it, then it waits 250 ms > (this can be set in Windows) and then sends another KEYDOWN's as long as you > hold down the key. The speed of autorepeat can be set in Windows as well, > normally it sends 30 KEYDOWN's per second on my computer (which is the > highest speed possible on a standard PC keyboard). Finally it always sends a > single KEYUP when you release the key. > > Caps lock sends initial KEYDOWN normally, then waits 250 ms (i.e. still > everything normal), but when you hold down the key longer, it starts to send > weirdly KEYUP - KEYDOWN - KEYUP - KEYDOWN... etc. at 30 events per second > (i.e. 15x KEYUP and 15x KEYDOWN). When you release the key, the final event > sent is based on the state of the green caps lock led on the keyboard. So > you > can never know if the final event will be KEYDOWN or KEYUP. > > I use Windows 7 with plain standard PS2 keyboard driver, at least I think. I > will definitely go and test it on other computers (I have a few old ones at > home). > > - > Mgr. Aleš Keprt, Ph.D. > private: a...@keprt.cz, www.keprt.cz > office: Moravian College / Moravská vysoká škola Olomouc, ales.ke...@mvso.cz
Re: ZX Spectrum 'relaunch'
For the purposes of debate, I think the counterargument would be that a software approach is inherently more portable and so more maintainable and more suited to a wide audience. Furthermore, there's no automatic advantage to doing things in hardware, given that these systems are fully deterministic and well understood, other than that it can be easier to get right, but that's primarily because the emulation mindset doesn't normally consider absolute accuracy to be a paramount concern. That's why you very often see people write emulators where interrupt timing is rounded to the nearest whole instruction, palette changes are accurate only to the nearest whole scan line, etc. Authors often prefer to make a subjective judgment about what's 'accurate enough' so that they can prioritise ease of development and/or performance. Summary then: emulation carries no inherent accuracy penalty. Alternatively, as a person who prefers functionality, surely you can see the benefit in emulation, which is all functionality and no form? The hardware becomes a completely orthogonal issue. On 13 April 2012 11:32, Aleš Keprt wrote: > I don't share your thoughts. There already exist a lot of Spectrum clones > based on real ULAs and real Z80 and imo these are much better alternatives > than what you described. You can already buy anything you can imagine. So > many alternatives already exist and were created by huge fan base in the > past, that I can hardly imagine that somebody can really come today driven > by just marketing or business visions and create something significantly > better or more compatible or more useful. > > For example: I personally prefer functionality, not the look of that crappy > original keyboard. So I would prefer a PC keyboard, CF memory card instead > of tapes or disks, and real ULA (i.e. 100% accurate ULA clone), standard 128 > KB RAM, and real Z80 CPU. > For other people who prefer or require the original ZX Spectrum case, they > can buy a new "internals" - this was already possible to buy 10 or more > years ago. (I personally has a working original ZX Spectrum+ and working > original Sam Coupe. :-)) > > I think you are too focused on emulators - why would anybody put a today's > computer with an emulator inside an old ZXS box? It's just funny, not > worthy. I prefer either emulator on a proper PC computer, or original 8bit > Zilog Z80 in an original box. :-)) > > Aley > > -Původní zpráva- From: war...@wdlee.co.uk > Sent: Friday, April 13, 2012 12:18 PM > > To: sam-users@nvg.ntnu.no > Subject: ZX Spectrum 'relaunch' > > Off on a bit of a non-SAM tangent (but probably somewhat related for > most of us) I came across this the other day: > > http://www.telegraph.co.uk/technology/video-games/8304237/ZX-Spectrum-relaunch-gaming-goes-back-to-the-future.html > > Lots of you have probably already heard this, but I don't remember it > being mentioned, so thought I would! ;-) > > Supposedly a company were going to relaunch the zx spectrum this year > (by the looks of it, as a 48k speccy keyboard that links up to an > iPhone or similar to run an emulator), to coincide with the 30th > anniversary, but it doesn't look like it's going to materialise any > time soon. I know something similar is/was being planned for the C64? > > However, it got me thinking... Obviously in this day and age, many of > use want to enjoy the retro gaming experience, but we haven't exactly > got the space to keep things set up. I intend to have my SAM set up > permanently at some point, but I very much doubt I'd ever get the > space to dedicate to other systems, so clearly something that > pleasantly replicates the original experience quickly and easily with > modern advantages would be a pleasing alternative. > > So I figured, what would make an easy to use 'spectrum' emulator for > playing all the old games? You'd want HDMI output for ease with modern > televisions, SD card storage, and have it all fit into one of our old > rubber keyed friends. How do you do this on a budget at that size? The > first thing that popped into my head, is the Raspberry Pi (if it ever > gets to selling!!). Small enough to probably fit in a speccy case, > with HDMI out and card reader. Surely this could make for a fairly > cheap and effective 48k Spectrum emulation experience? > > I think the Speccy is particularly suited, because let's face it, for > most of us it was about the games more than anything. I don't think > anything similar would work for the SAM, because what makes that such > a unique experience (for me, anyway) is the original and additional > hardware in addition to the software. But for a speccy I could see it > being great fun, to play the games with ease on a keyboard that > replicates the old experience but with updated advantages. (I think a > SAM equivalent would have to be more along the lines of Colin's > 'SAM-in-a-can' projects, but rather than old SAM parts, something that > accurately replicates the original hardwar
Re: ZX Spectrum 'relaunch'
2012/4/13 Simon Owen : > While I'm happy to stop short of bus signals for my emulation habit, I > do see the appeal in going down to that level to learn more about how > things work. An incredibly accurate emulation is just a handy byproduct > of the learning process :) I've enjoyed it because it makes everything fundamentally and unshakeably modular, just like the real chips, so you explicitly can't start cheating. So e.g. the ZX80 is able to use the R register for memory addressing only because it's exposed during the refresh cycle, rather than because I've given external components magical inner sight into my Z80. The design questions that arise from, essentially, making the bus the thing with agency are quite interesting. The major disadvantage is that because it's so compute intensive, it's just not a very popular way to proceed, meaning that the available documentation isn't always as helpful as if you were writing the traditional sort of emulator. So e.g. the situations triggering contention on the Spectrum are easy to express but when you've actually got to implement the floating bus as a floating bus that's a whole other set of considerations. This is, I think, the first time where I've had to read a schematic to implement an emulator.
Re: Musics
If I dare jump in, I'd phrase it the other way around. The source media is the authoritative copy; hacks and cracks are the compromises. On 20 April 2012 13:48, Aleš Keprt wrote: > Yes, but these compromises are needed for 1 disk of 100, while 99 of > 100 do work with DSK. So if somebody sends us his new ETracker tune in EDSK > format I ask myself: "Is this really what we needed?" > > Btw. I haven't seen SAMdisk utility before. It looks nice. I slept many > years or something. [image: Mrkající veselý oblicej] Please can you tell > me the format of TRD (Beta128 TRDOS images)? Is it the same as DSK? Or is > it like SAD without header? I read the documentation you link from your > website, so I know the internal data format, but I can't see the actual TRD > file format described there. Thanks in advance. > > Aley > > *From:* Simon Owen > *Sent:* Friday, April 20, 2012 10:40 PM > *To:* sam-users@nvg.ntnu.no > *Subject:* Re: Musics > > Aley, > > I'd started to type a longer reply to this, but I just can't be bothered > anymore. It's clear we have very different approaches to pretty much > everything. I'm just not willing to make the same compromises as you when > it comes to preserving media. If it doesn't work without modifying it, you > need a better quality copy. > > Si > > > On 20 Apr 2012, at 20:07, Aleš Keprt wrote: > > You know my disk extractor and other utilitie are dated 199x. > > And I don't like this. I think 95% or even more of disks overall don't > need any special disk formats, and there are many software utilities which > support simple DSK/MGT/SAD because those programs are much older than 2005. > It isn't a clever idea to design a whole new file format 15 years after Sam > Coupe was born and use it for all disks even when it is not needed for most > of them. Also those two SDF files can be downloaded from some websites, but > I haven't seen any protected EDSK files anywhere, so I would prefer > sticking with the same formats. "Don't change what works." Also this is the > first time I have seen EDSK file on my own eyes, and I wonder why it has > DSK extension when it is not a real old good DSK file. I looked at the file > in heax view and I can see Amstrad CPC header in it. Note that I created my > SAD format only because it was years before DSK format was known to me, and > also I have several 840KB disks which are a bit problematic in DSK > especially in some software which automatically expect 800KB DSK only. But > otherwise DSK is enough for most of disks. > > I think it would be OK if we had this file format around 1995 when there > was a real big need to backup our disks, but not in 2005 when 99% of disks > are converted and possibly cracked to be converted without any special file > formats. > > Aley > > *From:* Simon Owen > *Sent:* Friday, April 20, 2012 7:36 PM > *To:* sam-users@nvg.ntnu.no > *Subject:* Re: Musics > > On 20 Apr 2012, at 17:25, Aleš Keprt wrote: > > I'd like to know why do you use Amstrad CPC file format, instead of a > standard Sam Coupe one (DSK/MGT or SAD). > > > EDSK has been an adopted format in the SAM scene at least as far back as > 2005. It's the only way to preserve some disks in their original format, > allowing for unformatted tracks, disk errors and other custom-formatting > tricks. EDSK seemed like a reasonable solution at the time, without > inventing yet another disk image file format. > > Before that was finalised I did still create SDF as a temporary solution. > Only two public disk images ever existed (Lemmings and Prince of Persia), > and I don't think the creation tool was every released. All support for > SDF was dropped from SimCoupe a few months back, so it's effectively dead
Re: Musics
Attempting to vote takes me through to a blank page -- is that what you saw? On 20 April 2012 18:16, James R Curry <8...@itdoesntsuck.com> wrote: > It's a Wiki about the Sam world but has some disk images hosted which I > believe you can access from their product pages. It also has broken polls. > At least it did today when I tried to vote on one. > > -- > James R Curry > > > On Apr 20, 2012, at 8:13 PM, "Aleš Keprt" wrote: > >> Really? I didn't know it. Believe me, I don't lie, I never saw any EDSK or >> at least I don't remember any. >> I don't know much about World of Sam. It is something like NVG FTP archive? >> Aley >> >> -Původní zpráva- >> From: Andrew Collier >> Sent: Saturday, April 21, 2012 2:59 AM >> To: sam-users@nvg.ntnu.no >> Subject: Re: Musics >> >> >> On 20 Apr 2012, at 20:07, Aleš Keprt wrote: >> >>> I haven't seen any protected EDSK files anywhere, >> >> Almost all the previously-commercial software on worldofsam.org, for a >> start. >> >> Andrew >> >> >> - >> Mgr. Aleš Keprt, Ph.D. >> private: a...@keprt.cz, www.keprt.cz >> office: Moravian College / Moravská vysoká škola Olomouc, ales.ke...@mvso.cz >>
Re: Musics
The best idea I've come up with is to use a very limited number of tiles and scroll like one of those infinite ball demos. So, you have 8x8 tiles and 8 screen buffers. You scroll only either 1 or zero pixels at a time, only ever in one direction. Assuming it's a right to left scroll, for each movement you switch from one buffer to the next. Then run through each on-screen tile and paint only if that tile is not the same as the tile one position to its left. With a small number of possible tiles and a normal sort of platform game layout (ie, lots of horizontal platforms) you shouldn't have to draw all that much. Level two of Super Mario Brothers would probably be an ideal usage case. I guess that the next thing would be to store your tile map as the computed list of tile changes to draw per tile column, and to consider whether compiling your tiles so that you map from the combination of old tile and new to the code and draw only the changes gives a meaningful boost for the memory cost. I'm not sure whether anybody else has done this sort of thing, but I really mean to give it a go sometime soon. On Saturday, 21 April 2012, Adrian Brown wrote: > That’s top, im a child of the electronic sound – don’t think my wife is > too impressed with it blasting out of the office though ;) Im working on > some other sam bits at the moment (when time allows) For programmery > people, scrolling on sam is what let it down imho. Thinking of something > like sanxion, who has some ideas on how to move that much data. Im > guessing it would have to be mode 2 to really be able to get a decent speed > scroller. Ive tried various things for a decent speed scroll mode 4, but > it just doesn’t seem possible if you want a lot of graphics on screen, even > with compiled block data. > > ** ** > > Adrian > > ** ** > > *From:* owner-sam-us...@nvg.ntnu.no 'owner-sam-us...@nvg.ntnu.no');> > [mailto:owner-sam-us...@nvg.ntnu.no 'owner-sam-us...@nvg.ntnu.no');>] > *On Behalf Of *David Sanders > *Sent:* 20 April 2012 11:16 > *To:* sam-users@nvg.ntnu.no 'sam-users@nvg.ntnu.no');> > *Subject:* Musics > > ** ** > > Hello List, > > ** ** > > If anyone fancies a listen to the most fiendishly complicated piece of Sam > music I've written, here it is: > > ** ** > > http://dsanders.co.uk/sanxion.dsk > > ** ** > > It's kind of a conversion of Rub Hubbard's Sanxion loader, but done from > memory so probably quite different. I believe the effect at around 2:00 has > never been done before on the Coupé! A first time for everything even on > the Sam eh? So, why did I spend my morning writing this? Your guess is as > good as mine, but I reckon someone now ought to make the effort to convert > the actual game. Ahem. > > ** ** > > Cheers > > ** ** > > ** ** > > David > > ** ** >
Re: Nyan Cat
If it's for some sort of quick attempt at multipart megademo (albeit with all the parts being extremely similar), would it be safe to assume that someone [else] is working on the music? I'd love to be able to contribute but music is completely beyond me. Re: Aley's comments on a 4bpp 64-byte pitch mode (so, the same number of fetches as Mode 2, even with the same memory layout if they really wanted, but to produce a 128x192 display), I'd have been all for it, even as a replacement for Mode 2. Though obviously hardware scrolling would be quite a way above it on a wish list... On 23 April 2012 13:24, wrote: > Quoting Balor Price : > >> Hang on, am I really doing this??!! (reality kicks in) Hell no!! Not >> until I finish some /real/ stuff anyway >> >> Howard >> > > Do a send-up using the SAM Robot instead! :)
Re: Nyan Cat
I had a brief look at it; given that the originals are 400x400 (and, as you noted, not actually simply an upscaling of a smaller size, despite consciously adopting that look), I assume you repainted by hand? On 24 April 2012 11:13, Aleš Keprt wrote: > My conversion of original graphics is already finished, so I look forward to > your music. :-) > I wanted to ask for help the people who did music for some other 8bit > conversion(s). > Aley > > From: David Sanders > Sent: Tuesday, April 24, 2012 10:59 AM > To: sam-users@nvg.ntnu.no > Subject: Re: Nyan Cat > > > On 23 April 2012 21:34, Thomas Harte wrote: >> >> If it's for some sort of quick attempt at multipart megademo (albeit >> with all the parts being extremely similar), would it be safe to >> assume that someone [else] is working on the music? I'd love to be >> able to contribute but music is completely beyond me. >> > > I'm loathe to put myself forward for this, but what the hell. I'll convert > the music :-) > > - > 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
I guess it was easy to put in something like an optional shift right by three to compose scan line number and column number when fetching attributes, hence to allow Mode 1 and 2, but would have been harder to have alternative attribute interpretation logic? I'm unsure why they decided to go bright + flash in the Spectrum, to be honest. Was flashing a must have feature of the 1982 computer market? I think I'm right to say the American Timex machines have the equivalent of Mode 2? A pretend 64x96 mode could allow for some neat effects. I'll wager you could do Wolfenstein in it, based on the CPC seemingly being to cope in its 64-bytes-for-128-pixels mode, per YouTube. Following that line of logic through, anything on the CPC that isn't using a hardware scroll should be an option. 2012/4/24 James R Curry <8...@itdoesntsuck.com>: > The strangest decision regarding Mode 2 is keeping the BRIGHT and FLASH > attributes. Without those, the Ink and Paper colours could each be any of > the sixteen colours. As it is, the select colours have to both be in the > range 0-7 or 8-15, not one in each range. > > Incidentally, has anyone thought about clever use of Mode 2 and attributes > to create a game that runs at a super low resolution, like 64 x 96 (using > 4x2 pixel blocks)? > > It could run at a high frame rate... it might be an interesting experiment
Re: Nyan Cat
Agreed on James' comments re:Wolfenstein; from here in 2012, I'm much more able to suspend by disbelief for Elite, though I think Wolfenstein's problems go far beyond merely the style of graphics. I'd also forgotten the Manic Miner loading screen! Thank goodness for the flash attribute! On 24 April 2012 16:41, Ian Collier wrote: > On Tue, Apr 24, 2012 at 04:16:28PM -0700, Thomas Harte wrote: >> I'm unsure why they >> decided to go bright + flash in the Spectrum, to be honest. Was >> flashing a must have feature of the 1982 computer market? > > No but you forget one thing... the cursor. :-) > > imc
Re: Nyan Cat
Per The Register's extended article celebrating the Spectrum's birthday yesterday, there was more than a kilobyte of spare space in the ROM but they intended to put the Microdrive stuff in there before shipping. In the event it wasn't ready in time and the machine sold too well for the intended free ROM upgrade to make economic sense. So, with hindsight: • no flash attribute (ideally starting on the Spectrum, but at least in Mode 2); • a graphics mode that uses the Mode 2 amount of data for 128 non-attributed pixels per line; • hardware scrolling. Hooray for hindsight! On 24 April 2012 16:45, James R Curry <8...@itdoesntsuck.com> wrote: > Given that, at least going from my memory, there was space to spare in the > original ZX Spectrum ROM, the flashing cursor in Spectrum BASIC could have > quite easily been implemented with interrupts and each character square > could have had complete freedom to pick any two of sixteen colours. > > But what do they say about hindsight? > > > On Tue, Apr 24, 2012 at 6:41 PM, Ian Collier > wrote: >> >> On Tue, Apr 24, 2012 at 04:16:28PM -0700, Thomas Harte wrote: >> > I'm unsure why they >> > decided to go bright + flash in the Spectrum, to be honest. Was >> > flashing a must have feature of the 1982 computer market? >> >> No but you forget one thing... the cursor. :-) >> >> imc > > > > > -- > James R Curry > 8...@itdoesntsuck.com
Re: XOR now completed!
I played it for five minutes and it all looked very impressive. That being said, I don't actually know the original game so I was quite lost. Looking at the incredibly sparse World of Spectrum inlay scan though, I think I'm meant to work things out for myself? On 24 April 2012 18:00, Balor Price wrote: > Hello everybody > > I'm proud to present my conversion of the 1987 Spectrum game XOR. I finally > kept my promise to my teenage self to finish a SAM game! > > You can download it for free from the revived http://cookingcircle.co.uk > > I hope you enjoy it (and yell in frustration). It's 25 years old and still > as rock-hard as I remember. > > Any feedback/initial bugs found would be greatly appreciated. :D > > Cheers > Howard
Re: XOR now completed!
Being one of my favourite topics... the Wolfenstein algorithm is actually incredibly inefficient. It's a linear search for every column and then a couple of multiplies, an add and a divide to get scale. If you instead used a combination forward/backward renderer with portals and convex sectors, you could do significantly better for any sort of geometry you'd expect on that level of device. Assuming I've thought this through, costs Wolfenstein doesn't incur would be: per visible sector you'd end up at a quadrant test, a divide and a small table lookup per vertex, a divide, two multiplies and three adds per visible wall. But you'd then be looking at (much the same) two multiplies and an add every 8 or 16 columns and just two adds per column. So you're spending a little on setup to save a lot per column. You'd draw front to back, zero overdraw for the world. Sprites would be sorted per sector and I guess you'd want to walk back to the front in sector order to paint them in, making it a stack-type thing rather than merely a queue. Walls could be any angle, and costs would increase as geometry complexity increased, whereas in Wolfenstein they increase as your rooms get larger. But freely angle walls would probably allow you to keep the geometry simple. Disadvantages would be indeterminate, and usually larger, level data sizes, and the need to create a proper editor rather than just editing in TextEdit or Notepad or whatever. So, yes, I'm good at bluster. On 24 April 2012 23:18, wrote: > Just been having a quick play!! Love that it works so fast. :-) very cool to > see another new SAM game. How many is that now, in the last few months? Dave > Invaders, Garden Centre of the Universe and now XOR... :-) What next??? :-D > Those making them, should see about getting them mentioned in Retro Gamer > magazine. They've got a section in the magazine about new games for all the > old machines, with mini-reviews etc. Definitely worth a bit of free > promotion and seeing your game in print on the shop shelves. :-) > > I agree with the discussion that we all concentrated on emulating the 16bit > machines too much instead of working within the limitations to create other > stuff, but such is the way of things. We all wanted to do what the big-boys > could. Then again, that pushed a lot of the games further than a lot of > people expected anyway. I suppose that's another area where the SAM was like > the Spectrum. It wasn't technically as advanced as say the c64 in many ways, > but competed by sheer versatility and creativity. Such was the SAM to the > Amigas and STs. I think over the years the SAM has certainly proved it could > do great stuff, when pushed to its limits. Who originally thought Lemmings > would work? It's a shame we didn't see more games that weren't as limited by > speed, like Dizzy/Flashback types. > > > I'd love to see a basic test of a wolfenstein game running! :-) It'd really > be a nice show-piece. Having said that, if someone managed to get it > working, once the pseudo 3D engine of that was running, why not create the > SAM's own first FPS? (Like Colin was planning with Chrome) No need to use > the existing Wolfenstein graphics and such, when we can create our own for > the SAM, and our own level designs, story, creatures, etc? > > Warren > > > > > Quoting James R Curry <8...@itdoesntsuck.com>: > >> I remember ordering the original from one of those ZX Spectrum mail order >> places. They were never able to deliver it, for some reason, and offered >> me the choice of another game, instead. >> >> No idea what I wound up buying. >> >> Now I can finally play it. Looks good! Is it in Mode 4? >> >> On Tue, Apr 24, 2012 at 8:21 PM, Thomas Harte >> wrote: >> >>> I played it for five minutes and it all looked very impressive. That >>> being said, I don't actually know the original game so I was quite >>> lost. Looking at the incredibly sparse World of Spectrum inlay scan >>> though, I think I'm meant to work things out for myself? >>> >>> On 24 April 2012 18:00, Balor Price >>> wrote: >>> > Hello everybody >>> > >>> > I'm proud to present my conversion of the 1987 Spectrum game XOR. I >>> finally >>> > kept my promise to my teenage self to finish a SAM game! >>> > >>> > You can download it for free from the revived >>> > http://cookingcircle.co.uk >>> > >>> > I hope you enjoy it (and yell in frustration). It's 25 years old and >>> still >>> > as rock-hard as I remember. >>> > >>> > Any feedback/initial bugs found would be greatly appreciated. :D >>> > >>> > Cheers >>> > Howard >>> >> >> >> >> -- >> James R Curry >> 8...@itdoesntsuck.com >> > > >
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 >
Re: XOR now completed!
I'm unable to reproduce immediately, at least on short runs; I'm not sure if maybe my random hitting of keys (looking for that map key that I know must be somewhere) and inconsistency of choice between QAOP and 6789 may have been a factor. On the occasion in question I'd also played right the way out to 2000 moves. On 28 April 2012 15:50, Balor Price wrote: > Thanks for the feedback Thomas. > > I'm gonna take responsibility for the replay function - that sounds like my > bug somewhere. Something similar happened when I was playtesting but I > couldn't replicate the error. > > The 'level' system is a bit different from most other games - because there > are no 'lives' perse, when you finish a level it fills in a letter (or blank > sometimes) in the level table. Press up/down to select a different level to > play - they can be done in any order. > > Howard > > > > On 28/04/2012 23:39, Thomas Harte wrote: >> >> 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 >>> >
Fred 58: Sam Coupe book?
I've transcribed by hand (aside: is there an official transcription or extraction of the various Fred articles anywhere?) Page 5 and about two third of Page 6 of the editorial below. Did anything ever come of the project? "The big (BIG BIG BIG) news this month is that FRED will be publishing a book all about the SAM Coupe sometime this year. it is hoped that the book will be out in time for Christmas this year and will include many stories from people in the SAM world about their version of the SAM story, and any experiences they have had. Some stories are expected to be quite technical, while others will prove to be very funny. At the moment, Colin is getting in touch with everyone who could have a good story (including me...) and someone who is not involved will decide what will make the final version. "I must stress that the book IS NOT going to be a cheap, photocopied thing. It will be produced in the same way as any paperback novel, and could find it's way into some computer shops around the country. "Colin Mcdonald is funding the project entirely by himself, and although he expects to make a loss on it, feels that it is something that many of us would like to remember our times with the SAM. at the moment, price has not been decided. "The main reason for mentioning about this book so early is because we are still looking for SAM stories. If you think you have a story relating to the SAM which you think other people would be interested in reading about, please write down your experiences and send them to Colin. The number of contributions is likely to be very high, so unfortunately we can't guarantee to use your article, but please don't let this deter you from trying. We look forward to seeing what stories you have. The deadline is the 1st September, but the earlier the better." (sic)
Quick attempt at a scroller
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: Quick attempt at a scroller
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: http://www.clocksignal.com/dropbox/scroller-big.dsk It occasionally — and very obviously — leaps up to 50fps, having no frame rate compensation mechanisms whatsoever. I'm about 80% confident I can boost the speed to a reasonably constant 50fps, to drop to a constant 25fps with sprites and logic, for a simple enough game. On 15 May 2012 08:02, David Sanders wrote: > On 15 May 2012 01:42, Tommo H wrote: >> >> 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? >> > Surely a glut of Mario-style games is approaching! What's that? You've all > got real jobs to do? Excuses! > > > D > >
Re: Quick attempt at a scroller
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
That's really encouraging; I'm now obsessed with getting a complete game working at 50Hz and in that context I think even just two or three sprites would do it. The arbitrary 40% came from what was left over in the current demo but it strikes me it's also very close to the amount of time between line 192 and the next line 1 so setting a firm limit in that range resolves all potential concerns about sprite flicker (well, until I end up having to display a different three of the four sprites I really want each frame, or whatever). And once I have something working along those lines I can start seeing how well the scrolling holds up with more realistic map data. I've a few more optimisation ideas either way. On 18 May 2012 09:46, Simon Owen wrote: > On 18 May 2012, at 00:56, Tommo H wrote: >> 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? > > Maybe around 4-5 sprites of 16x16 pixels? IIRC my Pac-Man emulator has about > half a frame to draw 6 sprites of 12x12, plus a couple of background tiles, > including save/mask/draw/restore. For an extra boost perhaps generate the > sprite drawing code with knowledge of the data (like Chris did in SAM > Defender) — bonus points if you prepare that at runtime. > > It's nice to have some fresh on-topic content to read, so keep posting! > > Si >
Re: Wait for that game to load!
I'll embarrass myself by asking, I'm sure... how does one play a .m155? On 25/05/2012, Stefan Drissen wrote: > Sounds like a sanxionish remix? Wonderful instruments! And has a nice unique > artist sound to it! > > > > Regards, > > > > > > Stefan > > > > From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On > Behalf Of David Sanders > Sent: donderdag 24 mei 2012 12:08 > To: sam-users@nvg.ntnu.no > Subject: Wait for that game to load! > > > > I admit defeat slightly, but it was a valiant effort. > > > > http://www.dsanders.co.uk/oceanloader.dsk > > > > > > Cheers > > > > David > > > >
Re: Quick attempt at a scroller
I've gone with compiled sprites, and decided to ignore sub-byte masking, at least for now. That gave me 18 or 19 sprites until I wrote code to erase them afterwards, which cuts it to a measly 3. Suffice to say, I'm going to look into other approaches for that step; it's taking something like 6.5 times as long as drawing them in the first place. Anyway: http://www.clocksignal.com/dropbox/scroller-with-three-sprites.dsk On 19/05/2012, da...@properbastard.co.uk wrote: > Quoting Balor Price : > >> Aha you flatter me I'm not /that/ old :) (okay I'm 36) Yes indeed >> it is Splitting Images - it's another puzzler without any huge >> technical challenges, so I know I'm working within my comfort zone. >> I hadn't planned on making any changes with the personalities, but >> there are a couple of people who aren't immediately obvious, the >> speccy's version of Mick Jagger was terrible! >> >> I'd agree with Si on this one - unless you totally optimise each >> sprite you aren't looking at many. But there's masses of memory in >> the SAM so unless you're doing it to squash into memory-resident >> megademo, why not use that memory? There's often a direct trade-off >> of memory-for-speed (eg unrolling loops, making several specialised >> copies of routines) so go for it. >> >> Howard > > > Besides - if you needed to - it's always perhaps possible to load a > few random ones from disk... :) > >
Re: New SAM Game: The Lost Disks of SAM
I agree with Rob and with the other comments; and I'll add that the slow colouring in of the character to represent lives is a really neat touch. I'm a bit confused about what the enter key is meant to do on the info screen though — it seems to redefine black? On 31 May 2012 13:31, the wub wrote: > What a great game! The presentation is outstanding, you really have a > nice style graphically! I like the infinite lives/quick restart as it > makes for a very compulsive, "this time I'll do it" kind of feeling.. > > The fact you did this in a month makes you some kind of coding legend! :) > > Rob.
Re: BorderTron 3000 - SAM Coupe Edition
On vaguely these lines, is there any hope of an open source version? It'd be nice to add a native interface to it, FireMonkey having issues as you describe, and I'd also like to tie it in with the little tool I've written for compiling sprites (the shared palette being a reason to integrate the things). It'd be nice to be able to import PNGs too, which would probably be about ten lines if I can just use the built-in Cocoa stuff but I assume would be bucketloads of effort to do in a cross-platform manner, having to build and link to libpng, etc? On 6 June 2012 07:59, Simon Owen wrote: > On 6 Jun 2012, at 14:50, Chris Cowley wrote: >> I did think about limiting the editable area, but then SimCoupe has that >> nice "View Complete Border" option and I >> thought if I restricted it too much, somebody would say "Well, it'd be nice >> if it let you draw in the overscan area" :) > > Complete border isn't an authentic feature, but it does help with aligning > timing-sensitive code like yours. The default view area is balanced for > normal use, but you lose some lines from top and bottom. "TV-visible" adds > those back, and is needed to see the top border scroller above Lyra 3's > bouncing ball. TV-visible combined with the 5:4 display ratio option give > something that more closely resembles real SAM TV output, though on Vista and > Win7 it'll look a bit blocky I finish merging in the new D3D support
Re: Good resources for learning about the ASIC?
Maybe we should get some samples sent into the guys at visual6502.org who, despite the name, are attempting to image large swathes of old 8 bit ICs. See http://visual6502.org/donate_hw.html — they seem fine with broken hardware so does anybody have any faulty ASICs? Or spares? Possibly even just for sale rather than donation? On 10 June 2012 08:02, Adrian Brown wrote: > A nice pdf of the logic gate layout would be nice ... ;) > > -Original Message- > From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] > On Behalf Of Tommo H > Sent: 10 June 2012 04:31 > To: sam-users@nvg.ntnu.no > Subject: 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: Good resources for learning about the ASIC?
My only ASIC has exactly the same fault. Frustratingly it developed it on a Sam I'd bought from eBay only about four months before to replace the childhood one that's now long lost. That was about three or four years and I paid something like £100; looking now the two available seem to be £500 and £700, though neither appears to be moving at those prices. Is that really how much I should expect to pay if I ever need a third? On 12 June 2012 08:51, Leszek Chmielewski wrote: > I have a faulty ASIC, which displays no BRIGHT signal, so only 64 colours > available. But I need a working ASIC first, before I can donate mine. > > LCD > > Am 10.06.2012 22:52, schrieb Thomas Harte: > >> Maybe we should get some samples sent into the guys at visual6502.org >> who, despite the name, are attempting to image large swathes of old 8 >> bit ICs. See http://visual6502.org/donate_hw.html — they seem fine >> with broken hardware so does anybody have any faulty ASICs? Or spares? >> Possibly even just for sale rather than donation? >> >> On 10 June 2012 08:02, Adrian Brown >> wrote: >>> >>> A nice pdf of the logic gate layout would be nice ... ;) >>> >>> -Original Message- >>> From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] >>> On Behalf Of Tommo H >>> Sent: 10 June 2012 04:31 >>> To: sam-users@nvg.ntnu.no >>> Subject: 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: Accessing Sam formatted disks through a USB floppy drive
Being back in the UK for maybe three weeks and having uncovered some old floppies, and having no access to a PC with a floppy drive controller, did anyone try the Kyroflux route? On Thursday, 28 July 2011, Leszek Chmielewski wrote: > > >> > 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 >> > >> > It depends much on the disc drive. I had here some SAM discs which were > unreadable on PC or SAM, but a very good Drive I have for my +D was still > able to copy it to new formated disc, and I was able to copy almost all > files on my PC. The fail rate is very low. If the files are valuable for > you, I can try to recover them. > > Leszek >
Re: Accessing Sam formatted disks through a USB floppy drive
I've ordered one so I'll report on my findings when I have some. Sadly I'll just be preserving some of my own early creative work — I was about 11 at the time so it's nothing that would be of interest to anybody else. I'm not going to have anything of interest that's legal to distribute that isn't already freely available. On 24 July 2012 09:57, Leszek Chmielewski wrote: > No, but, read here: > http://www.softpres.org/news:2010-02-18 > Looks like it supports SAM Coupé. > I only do not know if it saves in MGT format. > > Am 23.07.2012 18:04, schrieb Thomas Harte: > > Being back in the UK for maybe three weeks and having uncovered some old > floppies, and having no access to a PC with a floppy drive controller, did > anyone try the Kyroflux route? > > On Thursday, 28 July 2011, Leszek Chmielewski wrote: >> >> >>> >>> > 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 >>> > >> >> It depends much on the disc drive. I had here some SAM discs which were >> unreadable on PC or SAM, but a very good Drive I have for my +D was still >> able to copy it to new formated disc, and I was able to copy almost all >> files on my PC. The fail rate is very low. If the files are valuable for >> you, I can try to recover them. >> >> Leszek > >
Re: Accessing Sam formatted disks through a USB floppy drive
Well, I've got a Kryoflux now, connected to the cheapest standard PC floppy drive that I could find on eBay, and it's working really well. The supplied software has a GUI (if you're willing to install Java, anyway; pleasingly it is OS X v10.8 compatible) and one of the output options is a raw MFM sector image, which ends up being a .MGT in Sam emulator terms. So the process is just insert disk, click 'start', adjust a file extension and repeat. It takes a bit more than one and a half minutes to do a good disk, obviously more if it ends up retrying sectors. My disks have been in my mother's (standalone, sheltered but uninsulated) garage for the last six years but were in a house for the 10–15 years before that and I'm probably getting an 80% read success rate. Total cost for interface and drive was about £100 but I've recovered lots of work by myself as a child so it was easily worth it; this is the first time I've had any means of imaging disks at all so I've not had an opportunity to rescue anything before. Definitely recommended for anybody else in a similar situation. On 24 July 2012 23:20, Thomas Harte wrote: > I've ordered one so I'll report on my findings when I have some. > > Sadly I'll just be preserving some of my own early creative work — I > was about 11 at the time so it's nothing that would be of interest to > anybody else. I'm not going to have anything of interest that's legal > to distribute that isn't already freely available. > > On 24 July 2012 09:57, Leszek Chmielewski wrote: >> No, but, read here: >> http://www.softpres.org/news:2010-02-18 >> Looks like it supports SAM Coupé. >> I only do not know if it saves in MGT format. >> >> Am 23.07.2012 18:04, schrieb Thomas Harte: >> >> Being back in the UK for maybe three weeks and having uncovered some old >> floppies, and having no access to a PC with a floppy drive controller, did >> anyone try the Kyroflux route? >> >> On Thursday, 28 July 2011, Leszek Chmielewski wrote: >>> >>> >>>> >>>> > 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 >>>> > >>> >>> It depends much on the disc drive. I had here some SAM discs which were >>> unreadable on PC or SAM, but a very good Drive I have for my +D was still >>> able to copy it to new formated disc, and I was able to copy almost all >>> files on my PC. The fail rate is very low. If the files are valuable for >>> you, I can try to recover them. >>> >>> Leszek >> >>
Re: text spooling
On 16 November 2012 10:38, Simon Owen wrote:
> For the other ports I was planning to use iconv to do the main
> transliteration step. Under Linux iconv (part of libc-bin) appears to
> include the support I'm after. Mac OS X is still using the traditional
> libiconv, which gives strange results with the accents separated out
> ("coupé" -> "coup'e"). If I can't find a quick and easy solution for
> that I'll just drop transliteration support. I'd rather spend my
> SimCoupe development time on emulation, not text conversion!
What's your policy on native code? I ran a quick test with:
NSString *testString = @"Coupé";
char terminator = '\0';
NSMutableData *asciiData = [[[testString
dataUsingEncoding:NSASCIIStringEncoding allowLossyConversion:YES]
mutableCopy] autorelease];
[asciiData appendBytes:&terminator length:1];
NSLog(@"%@ %s", testString, [asciiData bytes]);
Output was: Coupé Coupe
cStringUsingEncoding: directly on the string didn't do the job sadly
since it doesn't permit a lossy conversion and there's no direct
method for a lossy conversion with a C-style terminator.
Re: disassembling SamForth
As a slightly younger person (relative to the mailing list for a niche 80s micro, anyway) I'd no concept of the syntax or semantics of Forth until I read your site and a few sources on from that. Would it be fair to describe Forth as the procedural analogue of Smalltalk? I'm thinking specifically about strict left-to-right evaluation, words having meaning only by definition and runtime components doing the things that are usually specialised syntax like branches and loops. Both are also classically interactive environments with live feedback from which entire OSes sprung. Smalltalk is similarly typeless which I guess leads to the main distinction — that words are looked at dynamically depending on preceding words rather than statically and statelessly from a global store to create threaded code
Re: SAM / +D Help needed
I don't know anything about PAWS so can you give any information on how it all works? Do you end up with a compiled program or is it more like a binary you always reproduce plus the data files describing your game? Are there any visible differences between the Spectrum and SAM versions? Do you recall what steps you have to take to convert in the other direction? Are you aware of any other PAWS titles that remain available for both machines, which might allow the differences to be factored out? On 12 March 2013 18:25, wrote: > As the list has life signs - i'll try again :-) > > > > 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: SimCoupe / Trinity
How do the economics work out on this sort of project? I've seen, for example, $8000 raised on KickStarter for a CP/M machine — http://www.kickstarter.com/projects/2057605091/p112-single-board-computer-kit— but that was just for a new run of a fully designed machine that had been produced in the past and that is in many respects less complicated than a Sam (no video output, for example) and definitely an easier target to hit (eg, no specific bus timing is required). I feel that if you're going to produce a new Sam, whether upgraded or merely shrunk down, the way to make it an appealing product is to package it in its entirety into a thumb stick with, say, HDMI and USB ports for a TV and an optional keyboard, and either bundle every piece of software you can license onto a built-in ROM or give us an SD slot and hope that the market provides. Actually, Bluetooth is so cheap nowadays, maybe don't even bother with the USB port. But then you get to: why not just do it in software and install it on last year's mobile phone? On 3 May 2013 12:00, david brant wrote: > Yes but Bob wanted us to buy a ROM thing to sort out BASIC which I thought > was pointless. Most of the time it works fine unless you write a very long > program or use lots of DIM in it. But I've never written such big programs. > > If he come up with new hardware he may got better input or at listen to us > coders > > On 3 May 2013, at 19:49, Gavin Smith wrote: > > A super SAM-type project has been talked about since Bob Brenchley kept us > all going about his SamSon idea! If it's ever to happen, it will take > someone to do it off their own back and just see it through because most of > us on this list will be too skeptical and jaded to lend much support! I > think such a project might even have had a wider market if it had been done > years ago, before the Raspberry Pi. > > Colin has already got a 20+MHz Sam working with his prototype mayhem > accelerator and the last time he mentioned it in his mag, he was looking at > CPLD to reduce logic. He has also hinted in SR that a special issue would > cover a secret project he was working on so maybe it's related to a Quazar > Super Sam? > > Sent from my iPad > > On 3 May 2013, at 19:30, Leslie Anderson wrote: > > Would anybody buy it ??? How many SAM users would want one ?? And I'd have > to do costings to see how much the final unit would cost ! But if there are > people interested just let me know. > > > On 3 May 2013 19:13, david brant wrote: > >> Well what you waiting for if it that easy! No idea with hardware myself. >> >> On 3 May 2013, at 18:46, Leslie Anderson wrote: >> >> > Perhaps it's time for someone to design a NEW SAM COUPE. SAM II + or >> > Super SAM. What was done on the original SAM in dozen of chips could >> now >> > be done in about 8 distinctive ICs Then everyone could have a Super >> SAM! >> > >> > Z84C0020 Z80 CPU.. 20MHz >> > K6T4008 512Kx 8 bit SRAM >> > W27C010128K EEPROM >> > MAX EPM7512 CPLD 512 macrocells >> > SAA1099 Sound (PSG) >> > >> > >> > The MAX EPM7512 would be used to generate video, perform I/O, Memory >> > Decoding etc. The original ZX Spectrum ULA used about 144 macrocells, so >> > 512 should be enough. >> > >> > >> > On 3 May 2013 18:03, david brant wrote: >> > >> >> >> >> How about some means that you need the hardware to work on the PC,Mac >> etc >> >> > >
Re: SimCoupe / Trinity
Surely design and testing would be the real cost? Plus finding sufficiently many people to justify a PCB run? I'm way out of my depth here, correct me if I'm wrong. I read the Spectrum ULA book so suddenly I feel like a genius. On 3 May 2013 13:25, Leslie Anderson wrote: > Costings for a 'SAM Plus' would not be too high as the legacy ICs are > quite cheap : > > Z84C0020VEC or PEC about £1.50 > K6T4008 about £2.70 > W27C512 or W27C010 about £0.60 > EPM7512 Expensive £20 > SAA1099 about £1.50 > Plus : > AY-3-8910 PSG (Spectrum)about £1.75 > V9958+VRAM second VDP about £5 > > Miscellaneous ICs, 7805,DACs etc about £5.0 > > Resistors capacitors etc £5.0 > > Double sided board PCB approx £7.50-£10 multilayer board ??? > > Total Cost : > £55 ?? > > To design would take about six months or so...How many would sell , > even for cost ?? > > The real question is how many would be ordered and it is worth the effort > for such a small number ? > > > > > > > > On 3 May 2013 20:00, david brant wrote: > >> Yes but Bob wanted us to buy a ROM thing to sort out BASIC which I >> thought was pointless. Most of the time it works fine unless you write a >> very long program or use lots of DIM in it. But I've never written such big >> programs. >> >> If he come up with new hardware he may got better input or at listen to >> us coders >> >> On 3 May 2013, at 19:49, Gavin Smith wrote: >> >> A super SAM-type project has been talked about since Bob Brenchley kept >> us all going about his SamSon idea! If it's ever to happen, it will take >> someone to do it off their own back and just see it through because most of >> us on this list will be too skeptical and jaded to lend much support! I >> think such a project might even have had a wider market if it had been done >> years ago, before the Raspberry Pi. >> >> Colin has already got a 20+MHz Sam working with his prototype mayhem >> accelerator and the last time he mentioned it in his mag, he was looking at >> CPLD to reduce logic. He has also hinted in SR that a special issue would >> cover a secret project he was working on so maybe it's related to a Quazar >> Super Sam? >> >> Sent from my iPad >> >> On 3 May 2013, at 19:30, Leslie Anderson wrote: >> >> Would anybody buy it ??? How many SAM users would want one ?? And I'd >> have to do costings to see how much the final unit would cost ! But if >> there are people interested just let me know. >> >> >> On 3 May 2013 19:13, david brant wrote: >> >>> Well what you waiting for if it that easy! No idea with hardware myself
Re: Retro shows and Sam's 25th birthday
I’ve never been to one but would definitely try to make some effort if something like this were arranged. There’s a 90% chance it’d be while I’m out of the country but it’d be a good excuse to write something. On 24 Feb 2014, at 13:42, Andrew Collier wrote: > Hi, > > I guess the Sam's 25th birthday is coming up this year. > > I was wondering anybody regularly goes to any of the retro computer shows > which happen from time to time, and whether there would be any interest from > sam-users generally to meet up at one of them? If there's a good one towards > the end of the year we could perhaps arrange a few Sam related stands, and > 'adopt' it as a Sam's 25th anniversary event? > > Andrew >
