Re: New SAM!
That's quite a find. But one thing, the auction says: One of my pics shows the power supply without the plug and if you look closely you can see that the wires are tied up and completely unused., and: I have uploaded pictures of the test that I carried out. But the listing only seems to have one picture (the Sam in blue wrapping) and no obvious links to other photos. But maybe I'm being a dunce? On Fri, Jun 13, 2008 at 1:49 PM, Gavin Smith [EMAIL PROTECTED] wrote: I've a brand new SAM on eBay at the moment! It was won in a CVG magazine competition many years ago and stored in a cupboard all these years. Check it out if you're interested: http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItemitem=220245979532 Gavin
Grabbing floppy images
Hi, I have a Mac running OS X v10.5.3. I also have a USB floppy drive. Despite having previously refused to acknowledge any DOS formatted double density disks, the drive seems to have some success recognising Sam disks. But I don't seem to be able to successfully image a Sam floppy. I was hoping that somebody here who knows more about the way the Sam lays out its sectors and about the various UNIX tools might be able to help me. I'm attempting to image Arcadia Disk 3a, for no reason other than that it was first to hand and I'm confident that it is formatted in the usual Sam DOS way. Having identified my floppy drive as /dev/disk2 using Apple's Disk Utility, I tried the following at the terminal: dd if=/dev/disk2 of=floppy.dsk bs=512 count=1600 That produces the output: 1440+0 records in 1440+0 records out 737280 bytes transferred in 249.220053 secs (2958 bytes/sec) I also tried: d if=/dev/disk2 of=floppy2.dsk bs=2x80x10b And got: 0+1 records in 0+1 records out 737280 bytes transferred in 249.183222 secs (2959 bytes/sec) Both produced identical 720 kb files. When I try to boot either in Sim Coupe, I get the error 19 Loading error, 0:1. If I load Sam DOS from another disk and then try to do a dir on one of these images, I get a list of the first 18 files on the disk and the error 85 TRK- 0, SCT-10, Error 0:1. I'm aware that the number of sectors per track is different on the Sam and on the PC. This error makes me think that the drive is reading the disk per the DOS format and ignoring some of the Sam format sectors. In particular, I notice that 1600*512 = 2*80*10*512 = 800 kb, not 720 kb, which just happens to be the amount of data that MS-DOS puts on a disk. It strikes me that alternatively there is a disagreement between Sim Coupe and dd as to whether tracks should be stored in an interleaved format. But then I'd expect 800 kb images. Although I'm aware that my USB drive may be hard coded somehow not to support anything other than the PC layout, I am curious as to whether there is anything I can do about this. Anyone got any ideas? Even if I can't image original disks, is there any way I could use this drive for some sort of data transfer?
Re: Grabbing floppy images
Hmmm, so Sam DOS numbers tracks from 0, but sectors from 1? Or am I suffering a deficit of logic? Follow-on questions - does Pro-DOS use 9 or 10 sector tracks and/or is there a CP/M tool for imaging Sam format disks, I guess to multiple floppies if necessary? I guess it's best to contact Edwin directly with Atom Lite purchase questions, but it sounds like a compact flash formatted for use with the Atom is readable only by Sim Coupe? The Atom won't read disk images from a FAT32 volume on the compact flash and just make them looks like dfisks to the Sam? And I guess a Trinity Ethernet thingy from Quazar is equivalent to an Atom Lite from a storage point of view? I was actually thinking of getting a compact flash for my Nintendo DS and trying some homebrew - have you any opinion on the ease of porting Sim Coupe? The DS's native screen resolution of 256x192 is almost begging for it. On Mon, Jun 16, 2008 at 9:10 AM, Simon Owen [EMAIL PROTECTED] wrote: Thomas Harte wrote: Although I'm aware that my USB drive may be hard coded somehow not to support anything other than the PC layout That's pretty much it I'm afraid! USB floppy drives are seen as simple block devices, and the linear-CHS mapping is done inside the unit. I believe DD disks will always be treated as 9-sector 720K (and HD as 18-sector 1.44M), so be missing the 10th sector of each SAM track. I have heard rumours of USB drives with an unofficial way to change the geometry mapping in the drive, but I've yet to find one myself. Until someone creates something like a USB CatWeasel, you'll be unable to access 10-sector disks on a Mac. Even if I can't image original disks, is there any way I could use this drive for some sort of data transfer? You'd be much better off with an Atom Lite board in the drive 2 slot, so you can share a Compact Flash card between SAM and SimCoupe. It's faster, easier and more reliable than dealing with floppies. Edwin can provide them if you're interested. The USB drive situation could be improved, with specially crafted disks that lock out the 10th sector on each track. SimCoupe could assist by returning matching dummy contents for the inaccessible directory and data sectors. You still wouldn't be able to use existing 10-sector SAM disks, but 90% of the space would be usable on new ones. Si
Re: Grabbing floppy images
Various thoughts in response to this entire thread... I like Pro-DOS because it feels like a real operating system. But I've never seriously used it. It's a shame that CP/M didn't offer standard (albeit likely to be much-slower-than-native) graphics routines, or maybe there'd be a whole bunch of graphics adventures and 'useful' productivity software. I'll obviously need to save up for a Trinity or an Atom Lite. It's a shame neither do FAT32 + virtual images, even if it was just something like, e.g. having a read-only FAT32 partition on one part of the flash and a read/write Sam partition on the rest. Then at least only one piece of software for transferring from file system images to Sam-segment images would need to be written, for the Sam itself. And all PC OSs that can read/write cards and know FAT32 would work immediately. I'm actually not bad with low-level floppy formats and the WD177x having implemented a theoretically 'perfect' emulation of the latter for my ElectrEm project. I can't think of a reason for a normal, public domain program to go straight to the WD177x though, unless it really needed the memory that Sam DOS sits in. Maybe there's something I haven't thought of? I take it from the talk of different versions of B-DOS that the neither the Atom nor Trinity interfaces make any attempt to look like a WD177x in hardware? Re: the DS, I must remember to implement an optional 'square pixels' mode in my 3d engine. It'd be fairly easy to do as a tiny bit of dynamic reprogramming at runtime, though it'd probably mean you could see slightly further top to bottom. Or slightly less far left to right. Regarding that whole topic, some weekend work on the most critical segments has bought me a 20%+ speedup and I'm hoping to wring some more from the code overall. Next initiative: switch the face visibility tester to use a neat scalar/2d vector multiplication 'trick' that I'm sure everybody else thought of years ago — I'm loading the multiplier once to shift right and conditionally branch and simultaneously doing the multiplicand shift left and answer additions in both hl and hl' so as to multiply two multiplicands by the same multiplier for less than it would cost to do them individually. And I'm very, very proud of that. On Mon, Jun 16, 2008 at 2:45 PM, Steve Parry-Thomas [EMAIL PROTECTED] wrote: Steve Parry-Thomas has been using a Spectrum emulator to convert CPC CP/M images to a format that Pro-Dos can read. Edwin has also been working on storing CP/M images in Atom records, so no floppies needed there either. Yep! I have tried to restore a number of HiSoft Packages that were for the cp/m 2.2 system. Some files were missing from some of the images in the Amstrad archives. Missing files were found in the cp/m MSX archives! The files were moved to MS-DOS with a MSX disk image manager, then moved to a Pro-DOS floppy with 22Disk - dos program. Other files were in the wrong disk format, so loading the image into Spectaculator 7, then I can open the B drive as a 720 image and copy the files over into the new image, which SIM Coupe with Pro-DOS can read. There is around 60 new disk images on the Pro-DOS site, including a number of Infocom IF games , with HiSofts CP/M FTL Modula-2 coming later. Steve.
Re: Attempts at 3d on the Sam?
Sorry! Gmail identified this message and, so far, this message only as spam. So I haven't seen it until today... The only slight problem is that I'm dividing one fixed point 8.8 number by another, not one 8 bit number by another. Apart from having either a very coarse z-axis or a very short one, that would mean either that only objects at z=1 could rotate so that lines start from any pixel and, as a result, objects at further z values are incapable of being towards the outside of the screen, or that nearby objects were jumping all over the place. Much more than they already do (though I think I'm still mostly blaming limited sine table precision after several multiplies for that, but if implementing 2.14 fixed point for those limited parts doesn't fix it then I'll have to rethink). Anyway, one of the speed-ups I have recently made (subsequent to my Sam Revival submission) is a 64 kb table to turn perspective divides into multiplies. I'm actually using the table to get 64/z, doing a vector multiply with that on (x, y) then doubling x and adding half of its current value to y so as to multiply it by 1.5. Oh, except that I'm actually doing something like 62/z so as to avoid small clipping errors causing off-screen coordinates. All of that has more than halved the amount of time I spend on projection and finally made projection cost less than transform (which is 9 table-based multiplies and a lot of adding, and was the co-focus of this weekend's optimisation spree). I think I'm running out of optimisation ideas now, which is not to say that there aren't any, just that I haven't had them yet and may never have them. So it's time to start implementing an actual game. Would anyone be at all interested in my code, packaged as a public domain library of functions? I'll probably eventually do that anyway, but I'm curious. On Tue, Jun 3, 2008 at 4:51 PM, Geoff Winkless [EMAIL PROTECTED] wrote: Talking about division through multiplication and a table lookup, On Tue, 3 Jun 2008 08:28:21 -0700, Simon Cooke [EMAIL PROTECTED] wrote: Never implemented it, but the principle is sound. It's not tremendously different to a reciprocal table. I never implemented it on z80 but I did do the same on ARM (where it gives you a massive win since there's a MUL instruction but no DIV). Without wanting to teach egg-sucking, it's fairly simple in concept: you just multiply the two numbers then shift the result down. So to divide an 8 bit number in L by 14, you need to multiply by (256/14)= 18(ish) then use the H register as your result... so that gives you (effectively) L * (256 / 14) / 256 The 256's cancel each other out, so you end up with L * (1 / 14) Obviously there's a loss of accuracy but it does mean you can get away with a table of 256 bytes for an 8 bit divide. My problem is you still end up having to do a multiply, which (on z80) is way too slow. I'd be tempted to use a 64kiB divide table and to hell with it. Geoff
Re: New SAM!
Hmm, well I didn't win. But that's not surprising. Faintly nostalgia-ish question: if I got my Sam from MGT (I think), the Christmas immediately after the price for a machine with a floppy drive dropped to £200, what year is that likely to have been? I'm guessing 1991 or 1992... On Wed, Jun 18, 2008 at 12:19 PM, Gavin Smith [EMAIL PROTECTED] wrote: The TV screenshot is a crap pic - the overlay on the SAM test screen is from the TV itself (for adjusting colour etc). On 18 Jun 2008, at 12:09 PM, Leszek Chmielewski wrote: That's a bit bad, unfortunally it is not possible to edit (at least one day before auctions end), a eBay fault! There will be no second time for you to try, unless you stop the auction, but I would write something like SAM Coupé (SAM Coupe). I myself have two SAM Coupé so no need for it at moment, I just need a new drive, but this SAM does not have one, right? The current price is okay for a new SAM, so if I didn't had purchased a car this month, it would be a nice buy, even for a higher price and without drive. The TV Screenshoot looks a bit strange (cannot zoom it), maybe bacause it was the first ROM version? LCD Gavin Smith schrieb: Erm, in my infinite intelligence and perfectionism, I listed the new SAM as a SAM Coupé. This means that if you search for SAM Coupe you won't find it. DOH! It ends today (Weds) at lunchtime for anyone interested - I say this just in case someone searched for SAM Coupe and couldn't find it. No more spam, promise ;) http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItemitem=220245979532 On 13 Jun 2008, at 2:17 PM, Thomas Harte wrote: That's quite a find. But one thing, the auction says: One of my pics shows the power supply without the plug and if you look closely you can see that the wires are tied up and completely unused., and: I have uploaded pictures of the test that I carried out. But the listing only seems to have one picture (the Sam in blue wrapping) and no obvious links to other photos. But maybe I'm being a dunce? On Fri, Jun 13, 2008 at 1:49 PM, Gavin Smith [EMAIL PROTECTED] wrote: I've a brand new SAM on eBay at the moment! It was won in a CVG magazine competition many years ago and stored in a cupboard all these years. Check it out if you're interested: http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItemitem=220245979532 Gavin
Re: Grabbing floppy images
There are some USB to SCSI adaptors, which OS X fully supports, and SCSI floppy drives, but overwhelmingly they are of the LS-120 type, i.e. 100+mb 3.5 drives that are backwards compatible with old floppies. So probably they'd have PC geometry hard coded at a different place. What sort of floppy format were Apple using in 1997? Would obtaining one of the very original USB floppy drives that were intended for people moving to the iMac be of any advantage? On 22 Jun 2008, at 11:38, Leszek Chmielewski wrote: Simon Owen schrieb: Leszek Chmielewski wrote: You coded the fdrawcmd.sys? It should work with onboard floppy connector under Win2K. Yes, and yes :-) I changed the code from example HANDLE h = CreateFile(.\ \fdraw0, GENERIC_READ|GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL) to PureBasic syntax: Handle.l=CreateFile_(.\ \fdraw0,#GENERIC_READ|#GENERIC_WRITE,0,#Null,#OPEN_EXISTING, 0,#Null) but Handle returns always -1. I guess, that's not correct. The actual path being opened is \\.\fdraw0, but the backslash characters need to be escaped in C by adding additional backslashes before each. Try changing .\\fdraw0 to \\.\fdraw0 and see if that works. If it doesn't, check GetLastError() to see what it returns. If you're still having trouble, e-mail me off the list and I'll look into it. Thanks, it now seems to work, the handle is now every time 892. I never used C before, so I did not knew that trick :-[ . Btw.: you wrote, RealSpectrum Emulator use Fdrawcmd to read discs. I tried to read +D discs under Win2K, but Sector 10 is bad on every disc (Directory sector 10 is corrupted), SimCoupe reads all directory entries correctly. I guess RealSpectrum use a older version of Fdrawcmd, because it works fine only under Windows 98SE or older. The newer RS32 has no ability to read real discs. maybe it could be easier to use a standard SAM Disc, and create a dummy file, which has a Sector bitmap that reserves all sectors nr 10 on the whole disc. That's pretty much what I had in mind, but with additional dummy entries to reserve sector 10 on the directory tracks. 2 hidden entries can be added to each, to prevent the listing stopping so the remaining entries will be searched. I though, you want to modify SimCoupe to format and write discs with 9 sectors, that means, need to change the ROM, File Bitmap layout, etc. When the image is used in the emulator, saving will not use sector 10 in the directory since it has hidden files in it. The dummy file prevents sector 10 being used across the rest of the disk. Thats what I mean too. To write to a USB floppy drive would just need the 10th sector to be dropped, and the remaining 720K written to the raw device. When opening the USB drive in SimCoupe, the emulator will need to provide suitable dummy details for every sector 10. So you automaticaly can recognise USB Drives, I guess. I never used USB drives and have no Apple here, but Mac users have no other chance to connect a floppy drive, if they got no internal floppy connector. A Image of 256 Bytes of the last directory entry, which is precalculated and could be written on any disc, reserving sectors that are not accessable from PC. Any files saved after that on this disc, would be avoid writing these sectors, so no need to change SimCoupe. If there are more than 17 files on the disk, getting a directory listing would attempt to read track 0 sector 10. A SimCoupe change is still needed to return something for that read attempt. It would also be wise to block attempts to write to sector 10, since it can't be saved. Oh, I forgot about writting dummy sectors to directory sectors 10. So 8+1 Entrys needed, so this will reduce the number of saveable files to 71. But for data transfer needs it does not matter very much. The dummy entrys did not need to have a bitmap. Si Cheers! LCD
Sam timings
Hi, sorry — I've searched the various archives of the mailing list and just confused myself. So... In Mode 4, with the display switched on, is it accurate to say that: 1) the RAM gets a clock of 384 cycles/scanline 2) the display runs with a constant 312 scanlines/frame 3) for all but 192 of the scanlines, the CPU may access RAM on every fourth cycle 4) on the 192 scanlines with pixels on them, the CPU may access RAM every fourth cycle in the border, every eighth cycle during the display 5) pixels are generated for 256 cycles 6) so, on a scanline with pixels, you get 256 cycles in which you are allowed 32 memory accesses, and 128 cycles in which you are allowed a further 32 memory accesses So, e.g. if the following programs are executed from RAM then: ex de, hl add hl, hl add hl, hl ex de, hl (all 1 byte opcodes, native z80 timings of 4 cycles for ex de, hl; 11 cycles for add hl, hl) Takes 48 cycles (on the 6 Mhz bus) if executed in its entirety while pixels are being drawn, 32 cycles if executed in its entirety while pixels are not being drawn. The functionally equivalent: sla e rl d sla e rl d (all 2 byte opcodes, with a z80 native timing of 8 cycles each) Takes 64 cycles if executed in its entirety while pixels are being drawn, 32 cycles if executed in its entirety while pixels are not being drawn? Has anyone drawn up a neat table of all the opcodes with cycle counts computed as weighted probabilities of their timings if executed entirely in pixels and if executed entirely outside?
Re: Attempts at 3d on the Sam?
Oh, but it did also occur to me that I could create a convex-sector and vertical portal Wolfenstein-type thing for just an extra couple of multiplies per vertex. That'd mean you could use vectors to draw the outlines of walls but everything would be clipped so that there was no ability to see through walls; they'd look solid but all the same colour. The camera would need to be kept level anyway, so you could throw in some more explicit vertex mirroring and probably up the framerate. Then maybe use coherence stuff to produce a filled display, so you're mostly just extending or shrinking already filled areas of the screen frame-to-frame rather than having to carry the costs of a full redraw. Which I think you said was what Chrome was up to? If you wanted filled graphics then I guess you'd be looking at fixed height walls or arbitrary angle. So it wouldn't be exactly like Wolfenstein - you'd lose texturing but gain flexibility in shape. I think that's best attempted as a fork of the code though, so if I attempt it at all then it'll be after everything else is neatly tied up. I continue to dither over whether to switch to Jam from Pyz80. On Thu, Jul 10, 2008 at 7:36 PM, Thomas Harte [EMAIL PROTECTED] wrote: I'm still chipping away at optimisations, little by little. I've been distracted by my PC remake of the Freescape engine*, but haven't stopped working on the Sam stuff. The code is now roughly 28% faster than the version that I submitted for Sam Revival, and I'm not done yet. Filled polygons shouldn't be an insurmountable problem. In fact, they should be noticeably faster than the version from before I switched to vector outlines. The main problem is that not using the stack pointer for polygon filling will obviously slow that down by a huge amount, but continuing to use the end of frame interrupt for triple buffering and timing would lead to the occasional stray four pixels of random colour. In fact, it'd be very occasional because it'd only happen if the interrupt fired while the CPU was drawing the last four pixels of a scanline. I guess the final decision on what to do about that would depend on whether the engine was being used for anything that was meant to be close to a realtime game. My suspicion is that something sufficiently sparse that didn't run full-screen would actually be playable in real time with solid graphics. But I've yet to try to prove it. Incidentally, having watched I, Of the Mask a few times, I think it has exactly this problem — though obviously being a Spectrum game it leaves more 16 pixels of junk on screen. I'm not completely sure though. In terms of the engine's functionality, I'd like to get Elite-style movement (i.e. incremental rotations around local axes rather than Euler angles and progressive global axes) in there before calling it 'complete'. For a game, I prototyped a tennis game but it didn't seem to be fun whatever I did. So now I'm not really sure. * I know it's definitely not what this list is for, but Windows and OS X betas are available from http://tinyurl.com/66wr29 On 10 Jul 2008, at 16:06, Colin Piggot wrote: Thomas Harte wrote: I think I'm running out of optimisation ideas now, which is not to say that there aren't any, just that I haven't had them yet and may never have them. So it's time to start implementing an actual game. Anything in mind at this stage for a game, and how feesible would it be to impliment shading to the code as it stands? (going back to one of the original ideas of being like a Freescape style engine) Would anyone be at all interested in my code, packaged as a public domain library of functions? I'll probably eventually do that anyway, but I'm curious. Yeap, certainly. I had a few ideas on what could be done with the maths sides alone. Colin = Quazar : Hardware, Software, Spares and Repairs for the SAM Coupe 1995-2008 - Celebrating 14 Years of developing for the SAM Coupe Website: http://www.samcoupe.com/
Re: Attempts at 3d on the Sam?
Most of my thinking was just that if the left and right clip planes were freely positionable rather than hardwired to be at x = ±z then portal rendering would be extremely cheap. So if you're in a convex room A, which has one 'wall' W that is actually a doorway to convex room B then you can draw all of A, adjust the clip planes so that you're only allowing drawing to the left/right extent of W, then draw room B. And so on. With vertical fixed height walls you can get away with only supporting movable vertical clip planes. Of course, it'll look pretty jumpy if increasing precision in my matrix calculation stuff doesn't have a strong enough effect. But that's scheduled for after I've made some multiplication improvements. On Fri, Jul 11, 2008 at 10:58 AM, Colin Piggot [EMAIL PROTECTED] wrote: Thomas Harte wrote: Oh, but it did also occur to me that I could create a convex-sector and vertical portal Wolfenstein-type thing for just an extra couple of multiplies per vertex. Then maybe use coherence stuff to produce a filled display, so you're mostly just extending or shrinking already filled areas of the screen frame-to-frame rather than having to carry the costs of a full redraw. Which I think you said was what Chrome was up to? Yes, Chrome was just going to extend or shrink what was already drawn there, and redraw complete strips only when there had been a sprite drawn over the top. It was something I was thinking of - your maths could be used for that sort of style of 3D engine, and sounds like you have all the bases covered already! Essentially, just hold a map with the 2D wall positions, your maths code would then calculate which walls were visible and where, then just draw the walls - either vector or filled. Colin = Quazar : Hardware, Software, Spares and Repairs for the SAM Coupe 1995-2008 - Celebrating 14 Years of developing for the SAM Coupe Website: http://www.samcoupe.com/
Thinking aloud on polygon filling
I've not actually done any coding on my Sam 3d experiments in a while, but I have been thinking a lot about the best way to implement polygon filling. I had a polygon filler working in a much earlier version of my code (see, e.g. http://uk.youtube.com/watch?v=kr_Lz98qVjE from about 0:39) but it only did triangles, didn't clip and generally wasn't really up to snuff in several ways that hit the frame rate. Anyway, I've been playing around with a few ideas and was wondering if someone with a more instinctive grasp for this sort of thing might help out. I previously tried using a span buffer. Each pixel span (i.e. a horizontal line of pixels) was inserted into a linear list of existing spans for that scan line, by clipping it against the spans that were already there then shuffling things around in memory. So there was a binary search and then often a small LDIR. The entire frame was drawn at the end. I even tried a system whereby each span list was compared with the previous span list and only the differences were plotted. That was much faster than just dumbly drawing the whole list, but slower than just plotting the spans to the screen and not doing the list search and insert. Furthermore, as you add more polygons to the scene, the insert gets more expensive very quickly. Idea 1 is to divide the screen into 8×8 blocks, keep an overview that tags each as either block filled with a certain colour or messy. The polygon filler tags as many blocks as possible as completely filled, and consults modifies a 1 bit mask for each run of 8 pixels in a messy block. So searching the existing structures for each individual container is faster because it's O(1), and you're doing exactly as much searching as you were for a 64×64 rectangle, then maybe less or maybe more depending on the relative dimensions. As there are only 256 possible masks for each 8 pixel messy area, you can easily write 256 separate functions for that part of the insert (or have a program generate them). But you need to do some extra work to figure out how the polygon maps to each 8×8 block, whereas you need to know where it starts and ends in each scan line regardless. You're potentially keeping a 1 bit version of the entire display as well as the real screen, but that neatly fits onto the end of each screen's 32 kb page, conveniently ending exactly before the start position of my multiplication tables. Of course, messy areas are directly plotted to the display as they are drawn, solid colour blocks are drawn in a separate pass at the end, and not redrawn if they were the same colour in the preceding frame. Idea 2 is a closer modification of what I had. During the normal draw phase, spans are stored to a buffer, but this time in no particular order. At the end of frame, the spans are sorted and mutually clipped through the creation of a binary tree. Possibly the tree is serialised and compared to the previous span list at the end, to reduce overall drawing. So searching costs the same as it did, but inserts are cheaper and their costs grow much less quickly. Building the tree scan line by scan line at the end means I can throw 32 kb or whatever at the tree for each separate scan line (since the contents aren't interesting after it has either been drawn or serialised). Idea 3 is a brute-force memory bashing version of the original. Each scan line is now represented by 512 bytes of memory. That amounts to two bytes associated with each screen pixel. If a span starts in that pixel then its end location and colour are stored. So searching is linear, but inserting is as cheap as can be. Some sort of bucket system could be implemented, e.g. not allowing any scan line to pass the next 32 pixel boundary — so writing new spans to the intermediate buffer might require up to 8 writes, but searching is much faster. Serialising can be done at the end of frame to compare to the previous display if necessary. Anyway, I really can't decide which way to go. And there are probably other, better ideas. Is there any expertise on this list on this sort of thing?
Re: Random Sam BASIC question.
I meant are they read/write, or write only? However in the interim, I've found a copy of the Technical Manual online and discovered that they are read/write, which I wasn't expecting. On 28 Aug 2008, at 21:06, Leszek Chmielewski wrote: 251 = High Memory Page Register 250= Low Memory Page Register Greetings, LCD Thomas Harte schrieb: Port 252 is read/write? Anybody got any idea about ports 250 251? On 28 Aug 2008, at 20:22, Leszek Chmielewski wrote: James R Curry schrieb: Okay, utterly random question... How does one determine the start address of the screen in Sam BASIC? I forget. It has been years. -- James R Curry [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] SAM adv. technical manual says: 10 LET A=IN 252 BAND 31 20 LET BASE=(A+1)*16384 BASE=Start of Screen greetings LCD P.S. But the structure of Information in Screen$ for Palette interrupt changes is unknown to me yet. |-D.
Re: Random Sam BASIC question.
To be honest, I houugh Acorn Electron has the same processor as C64 and Atari XL, and I was sure, they hawe no Ports and anything is memory-mapped (By the way, I currently extending my Retro-X to Acorn Electron and Amiga screen conversion, is your Electron Emulator probably for SAM???). Everything is memory mapped, but it's still registers at addresses, you just use the regular load/store instructions to write to them. The only difference of the z80 versus the 6502 is that it has a 17-bit address, adding a second 64kb can only be accessed by a IN/OUT. My Electron emulator is for the PC/Mac, but I haven't released a new version in years. In any case, if you have any questions about anything on that front, feel free to drop me a line. Releasing your 3D engine for others is a great idea, I saw the Videos on YouTube, I think, you can improve the speed of line drawing by optionaly draw every second pixel of the line on screen (like Mercenary on Speccy). That would definitely help. There's quite a few more things I can do to speed it up without affecting the graphics first though. It's just finding the time. I think I'm relatively lucky because I don't work in anything to do with software so I don't end up with programming fatigue from my real life. I'm also giving serious consideration to knocking up a quick BASIC dialect to try to increase the code's reach to non-ASM people and make it more likely that some actual titles will be released. But if I manage that then it'll be through a PC/Mac-side compiler rather than any sort of Sam-based interactive environment. Excellent idea (that is something I was planing for Retro-X, but as Cross-Suite, with supply for multiple Machines, with modern BASIC dialect and comfortable Scintilla-Based editor. Unfortunally I was never very good at coding in Z80 assembly, and using ROM Routines), I'm looking forward to see your work, as you are much more gifted coder than I'm. Oh, this stuff is all much easier now than it must have been in the 80s. And it's not just the wide array of information that is accessible through the internet, when I was learning 3d I found out that Elite achieves its near-solid look just by using convex objects by directly asking David Braben. Let's not pretend you would have been able to get that sort of help when that sort of information actually had commercial value.
Re: Speed issue's with POINT (x,y)
You're quite right — some hasty testing in Sim Coupe reveals that it is much slower. I was imagining that POINT might go through some arcane paths with all the xos/yos/xrg/yrg stuff. If you have the memory to spare, could you maybe skip over the problem by allocating a new screen that is never shown to the player, then in advance (maybe just after the level has been loaded?) plotting a colour at each position that represents what should happen when the ball is there? It'd mean you could cut yourself down to using a single POINT. On 18 Sep 2008, at 15:37, Geoff Winkless wrote: On Thu, 18 Sep 2008 13:26:15 +0100, Thomas Harte [EMAIL PROTECTED] wrote: Maybe something like the following to get the colour of the pixel at (x, y): 10 LET A=IN 252 BAND 31 20 LET BASE=(A+1)*16384 30 LET ADDR = BASE + (x/2) + y*128 40 LET BYTE = PEEK(ADDR) 50 IF x BAND 1 THEN LET COL = BYTE/16 ELSE LET COL = BYTE BAND 15 I can't believe that would be any quicker (in fact I'd be amazed if it's not slower) than POINT(). The way to improve the speed in a generic way is to write machine code that checks the edges of a bitmap you pass it and tests the appropriate points on the screen. The _fastest_ way is to write a specific set of checks based on the sprite and the direction of movement. Basically, let's say you figure out that if you're moving upwards you need to test pixels 2 to 6 on line 0 and pixels 1 and 7 on line 1. Your code for test-up would therefore be LD A, (IX+1) # pixels 2+3 OR A, (IX+2) # pixels 4+5 RET NZ OR A, (IX+3) # pixels 6+7 INC I:IX (or whatever your assembler uses for that non-instruction) OR A, (IX) # pixels 0+1 line 1 AND 0F # isolate rightmost pixels RET NZ OR A, (IX+3) # pixels 7+8 line 1 AND f0 # isolate leftmost pixel RET IIRC if you call this with USR you get the value in A as the result (or is it BC? Can't remember), so you can just IF USR(upcode)0 THEN GOTO HIT There are ways of passing parameters to USR functions, I can't remember how though :( I'm also not sure if using IX is better than INCing H and L (probably not) The problem with POINT (or similar) is that it has to completely recalculate the positions in memory for every check. That's slowed down even further because each time it has to access the values from BASIC's variable stack which (since it's all floating-point and they're stored in a non-optimal way) is ridiculously slow (it's a shame Andy Wright didn't see fit to add integer variables like you get in BBC Basic, for example) Geoff
New projects Byte-Back 2009
Through an uninteresting, indirect route, it seems likely that I'll be attending and supplying a Sam for the homebrew area of Byte-Back 2009 (http://byte-back.info/ ), one of those classic gaming convention thingies, which will occur in Stoke-on-Trent on March the 7th and 8th next year. Consequential questions: 1) Will anybody else be in attendance? 2) Is anybody willing and able to transfer some of my Sam programs to actual Sam floppy in preparation for the event? I guess I'll want to take all of my current 3d stuff and maybe another thing that I've just started messing around with. 3) Does anybody else have anything I can take along? Obviously the tag 'homebrew' doesn't mean that much in the Sam world, but in the context of all the information available I'm interpreting it just to mean new stuff for old hardware.
Re: New projects Byte-Back 2009
Oh. Well I've booked a ticket and a hotel room, so I'm hopeful it'll go ahead. There certainly seems to be a lot of interest at the Retro Gamer forums (http://www.retrogamer.net/forum/viewtopic.php?t=10861highlight=byte ), and a whole bunch of people from the BBC emulation community are planning to go, which is where I heard about it from. Per the Retro Gamer forum, the most local hotel is already booked up. That said, I've never attended or paid that much attention to this sort of thing before, so I've absolutely no baseline of interest to compare it to. I've only ended up with the offer of a table because I posted to the Byte Back forum and asked if homebrewy stuff would be welcome. I guess if the show occurs and the offer was genuine, I'll probably be in some corner with a Sam, an Electron and a Mac, showing my Sam 3d stuff, some Electron stuff as yet unwritten and my OpenGL 3d Construction Kit-compatible Freescape implementation. If that makes me unofficial custodian of all Sam content in the 'homebrew' corner then I'd really love to have more than my momentarily-interesting 3d routines to show. On 23 Sep 2008, at 21:58, Steve Parry-Thomas wrote: Interesting that's on my door step! There has been one or two of these in the stoke area that's never quite happened. If this one goes ahead, then yes, I could be there with my SAMs and Jupiter Ace Archive Steve(spt). -Original Message- From: [EMAIL PROTECTED] [mailto:owner-sam- [EMAIL PROTECTED] On Behalf Of Thomas Harte Sent: 23 September 2008 21:40 To: sam-users@nvg.ntnu.no Subject: New projects Byte-Back 2009 Through an uninteresting, indirect route, it seems likely that I'll be attending and supplying a Sam for the homebrew area of Byte-Back 2009 (http://byte-back.info/ ), one of those classic gaming convention thingies, which will occur in Stoke-on-Trent on March the 7th and 8th next year. Consequential questions: 1) Will anybody else be in attendance? 2) Is anybody willing and able to transfer some of my Sam programs to actual Sam floppy in preparation for the event? I guess I'll want to take all of my current 3d stuff and maybe another thing that I've just started messing around with. 3) Does anybody else have anything I can take along? Obviously the tag 'homebrew' doesn't mean that much in the Sam world, but in the context of all the information available I'm interpreting it just to mean new stuff for old hardware
Re: Speed issue's with POINT (x,y)
What sort of values can those nine variables take on? If it's just two possibilities (e.g. overlapping or not overlapping) then you could package them into nibbles in fours, store the nibbles as pixel colours to unseen screens and reduce your number of POINTs from 9 to 3. It's essentially pre-calculating the results for each pixel on screen and storing them in an integer array that BASIC understands how to index. On 24 Sep 2008, at 17:36, Calvin Allett wrote: Firstly would like to apologize to Thomas and Geoff for not getting back to this, ended up going out on p*ss other day and completely forgot I'd posted on here, hehe (been gonna ask so many times over past year :) )... anyways, Yahoo won't let me reply to your emails for some reason, so I'll just have to post here. Yeah Thomas, as Geoff said about calculating the value's of pixels myself, and as you've found out, way to slow, I actually tried the same thing last year with variables, i.e. just storing values in RAM myself and updating and seeking them from their locations instead of using variables, thinking it would cut out looking up the variables, but that too ended up slower :( Really am trying every trick I can to make Basic be capable of the things I want, and must say that the amount of months I spend polishing and speeding things up with tricks It'd be quicker to learn MC, but as I've said I honestly wouldn't enjoy coding then ;) The thing you said about keeping a copy of the screen and having pixels to check for what happens to the ball is a very good idea, already doing that with a Screen 3 (as 1 and 2 are used for screen flipping), so that when there are sprites on screen, I can still check for background colour and have movement correct... Did think about using a 4th say, as you suggest to perhaps make finding of the pills a bit easier, but that would mean doing yet more more POINT test, and I really need to be doing all the others anyway (L,R,T,B,B2,B3,B0,BR and C) as basically the game is one big collision detection engine, everything from the movement, background, enemy collision and pill finding is done using those 9 variables, and they all need to be done every frame :( , which leads me on to what geoff discussed. Geoff, it's a crying shame that SAM or Masterbasic hadn't offered integers, being a lamer, hehe, I wouldn't know how much time it would save, but anything counts right :) I made sure with calculations to try and use integer only for this game (apart from Y variable which sometimes isn't)... Couldn't understand the MC you posted but I get what you mean about only finding address of coordinate and then using offsets to speed up routine, I notice there was very little code, were those few lines all it takes to find the value's and move on to next point to check etc? ... I always imagine that for any 1 command in basic it'll take perhaps 10-30 lines (or more) in MC to accomplish the same thing. The way it works at moment it can't just always check say the pixels to the left if the ball is heading that way, as the way levels are drawn you might be jumping down a curved passage way, so that each frame the ball is getting projected out and away from anything it comes into contact with, and sometimes that might be from all around the ball. I finally got it so that even though you can get very close, the ball never lets you squeeze into the scenery, so that makes it look nicer. anyways, I don't really know what to do at the moment, but will try and post a couple of vids up later so it can be seen how much it's slowed down with more point checks... ;) Thanks again lads, without being able to talk about coding I'd probs still be across the road getting pi**ed EVERYday with 10 pissheads instead of enjoying the SAM, lol *_+ Cal...
Re: Speed issue's with POINT (x,y)
I agree with Simon; I especially like the way the ball crushes itself to go through short spaces. On Sat, Sep 27, 2008 at 1:52 PM, Calvin Allett [EMAIL PROTECTED] wrote: another vid http://www.youtube.com/watch?v=14m21hySxG8 Older versions, one faster, one slower:- http://www.youtube.com/watch?v=U0ksam2anMI http://www.youtube.com/watch?v=L8s4yb8zMMQ Cal... Calvin Allett [EMAIL PROTECTED] wrote: Thanks Simon :) Of course it's for the 20Mhz SAM, so I really should have it running a lot faster, even in basic... Simon Cooke [EMAIL PROTECTED] wrote: That's looking pretty solid dude J Si From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Calvin Allett Sent: Friday, September 26, 2008 1:29 PM To: sam-users@nvg.ntnu.no Subject: Re: Speed issue's with POINT (x,y) http://www.youtube.com/watch?v=2RenBQ5GD24 That's nearly half the speed that the engine was just 4 weeks ago eek, hehe P.S. I put a video up on my YouTube page, but it hasn't gone live yet, will post when it does !
Re: New projects Byte-Back 2009
Having further discussed with the organiser of this event, I have agreed to supply at least one SAM Coupé for their The Weird and the Woeful (obviously as an example of weird) section, with a bunch of software from its commercial period and maybe a disk or two of modern homebrew in addition. Having had a quick check of my floppies, I intend to bring the following: Sam Strikes Out/Futureball Escape from the Planet of the Robot Monsters Batz'n'Ballz (though I have no mouse) Tetris, from the most recent Sam Revival Sphera Probably some copies of Fred Obviously this leaves a whole bunch of massive holes in what I can show; is anybody able to loan copies of Prince of Persia, Lemmings, Defender and anything else particularly worth showing? Incidentally: the latest on my 3d code is that it's relatively close now to just being neat library code. So if you're an assembly coder, you'll be able to download it, read a couple of pages of documentation and get on with writing a game or whatever. Future internal fixes and improvements should benefit any projects built against it but not require them to be changed or to have any real knowledge of the internals, like all the best libraries. Hopefully some sort of BASIC- or-similar language for utilising the code will be forthcoming after that. On 23 Sep 2008, at 22:38, David Brant wrote: - Original Message - From: Thomas Harte [EMAIL PROTECTED] To: sam-users@nvg.ntnu.no Sent: Tuesday, September 23, 2008 9:40 PM Subject: New projects Byte-Back 2009 Through an uninteresting, indirect route, it seems likely that I'll be attending and supplying a Sam for the homebrew area of Byte-Back 2009 (http://byte-back.info/ ), one of those classic gaming convention thingies, which will occur in Stoke-on-Trent on March the 7th and 8th next year. Consequential questions: 1) Will anybody else be in attendance? Not likely unless I move house. Its a bit too far 2) Is anybody willing and able to transfer some of my Sam programs to actual Sam floppy in preparation for the event? I guess I'll want to take all of my current 3d stuff and maybe another thing that I've just started messing around with. Yes no problem. 3) Does anybody else have anything I can take along? Obviously the tag 'homebrew' doesn't mean that much in the Sam world, but in the context of all the information available I'm interpreting it just to mean new stuff for old hardware. I'm working on program at the moment, so may have something by then.
Re: New projects Byte-Back 2009
Oh gosh, I've just realised how that reads! To be clear: I consider the massive holes to be obvious, Prince of Persia, Lemmings, Defender to be a subset of the obvious list, and I intended anything else particularly worth showing to be a request for impressive titles that may not be obvious. I certainly didn't mean to imply, and definitely don't believe, that Prince of Persia, Lemmings and Defender are the complete list of Sam titles that I subjectively consider to be worth showing. On 7 Oct 2008, at 21:23, [EMAIL PROTECTED] wrote: Quoting Thomas Harte [EMAIL PROTECTED]: Sam Strikes Out/Futureball Escape from the Planet of the Robot Monsters Batz'n'Ballz (though I have no mouse) Tetris, from the most recent Sam Revival Sphera Probably some copies of Fred Obviously this leaves a whole bunch of massive holes in what I can show; is anybody able to loan copies of Prince of Persia, Lemmings, Defender and anything else particularly worth showing? Manic Miner! Defender! Stratosphere!
Tiny sound programming query
Roughly how much code (in kilobytes) is the part of an average end-of- display interrupt driven music player that actually resides in the interrupt handler?
Re: Tiny sound programming query
Yeah, I don't really know what I mean. I have a good understanding of exactly how programmable sound generators work (in that I've written cycle-perfect emulators of them) but I've no musical talent whatsoever so how you build actual music from that is something that I have an extremely nebulous grasp of. The real foundation of my question is that I'm busy trying to figure out exactly what I need to support to allow audio playback to work with my 3d library stuff. At the minute it's possible for a user to supply extra code for the interrupt handler, I was just wondering how much room I needed to leave in the interrupt handler to allow someone who understands what they're doing to lever in a music player. I guess I'll allow a small number of bytes and stop being so protective of the 32 kb I was saving for faster multiplication code. So one could chuck the ProTracker or E-Tracker tunes and player into the spare 32 kb and then just page and branch in the IRQ handler. The IRQ handler is going to have to be sandwiched onto each and every one of the already-cramped video pages, so keeping it minimal is a priority. Work-in-progress documentation of the library here, by the way: http://members.allegro.cc/ThomasHarte/temp/Lib3d.pdf (~112 kb). It's all about the interface you'd use if you were going to use my library. I don't think it's the place for documentation of the internals or my various bits of work on tweaking and optimising; that stuff will continue to be the subject matter for SAM Revival for now. Please anyone feel free to comment or criticise. On 7 Oct 2008, at 23:13, Andrew Collier wrote: On 7 Oct 2008, at 22:42, Thomas Harte wrote: Roughly how much code (in kilobytes) is the part of an average end- of-display interrupt driven music player that actually resides in the interrupt handler? Hi, That depends what you mean... The code you would write in an interrupt handler would need to: 1. page in the music player (if necessary) 2. call the player routine (often at 32774) 3. page back the previous memory state (if you changed it in step 1) and is just a few bytes. The music player itself is much larger, and depends on which music system you use. A compiled E-Tracker tune is a few k depending on its size - all of that needs to be paged in when you use it. The first 1202 bytes of this are a player code routine which is the same for all tunes, the rest is data specific to each tune. A compiled ProTracker tune is larger (partly because the effects are more complicated, but mostly because I was concentrating on execution speed, rather than code size, when I wrote the compiler). The player routine is about 12k including some tables of sine waves and things; the data for a particular tune is usually somewhere between 8k and 16k. Both systems expect the whole music player code to be played once per frame. There isn't support for, say, filling up a buffer of a few seconds worth of music, and just playing from the buffer at interrupt time. (That said, if you have a particular need for this, it might be relatively easy to hack up the ProTracker player to support doing that. Bear in mind it is decade-old code, though...) Cheers, Andrew -- --- Andrew Collier http://www.intensity.org.uk/ --- --
Re: New projects Byte-Back 2009
I'm not sure that I disagree. Furthermore, I don't even like the real Eric Clapton. However, I have already booked myself a ticket. On Wed, Oct 8, 2008 at 10:04 AM, Geoff Winkless [EMAIL PROTECTED] wrote: On Wed, 8 Oct 2008 09:54:31 +0100, Thomas Harte [EMAIL PROTECTED] wrote: Stoke-on-Trent, on the 7th and 8th of March 2009. The website is here: http://www.byte-back.info/ Tickets are currently £10, but the website implies they'll become more expensive at some later date. Seriously? _more_ than a tenner? Come and see a 25 year old Outrun cabinet (which you wouldn't even pay to play in the arcade any more) and watch as a middle-aged baldy tries to pretend he's Eric Clapton. A tenner would be the _upper_ end of what I'd expect to pay, unless the website isn't doing justice to the event. Geoff
Re: New projects Byte-Back 2009
Stoke-on-Trent, on the 7th and 8th of March 2009. The website is here: http://www.byte-back.info/ Tickets are currently £10, but the website implies they'll become more expensive at some later date. The website forum is a bit dead, but there seems to be lots of interest in other UK-oriented retroy forums around the net. On Wed, Oct 8, 2008 at 8:27 AM, [EMAIL PROTECTED] wrote: Quoting Simon Owen [EMAIL PROTECTED]: Thomas Harte wrote: is anybody able to loan copies of Prince of Persia, Lemmings, Defender and anything else particularly worth showing? I'm planning to go to the show too, so I should be able to bring any software (or even extra hardware) you need. I've got a SAM In A Can too, with Quazar Surround, SID interface and Atom Lite , if that'd complement a traditional SAM machine on show? Si Where / when is it - as I happen to have one as well ;)
Re: A little bit of news....
Good work × 2! On 2 Dec 2008, at 09:17, Adrian Brown wrote: Girl, Megan Rose Brown, born 26th April, everyone is fine - thanks for asking. Hoping to get some http stuff working soon :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Parry-Thomas Sent: 02 December 2008 00:46 To: Adrian Subject: RE: A little bit of news Great! And congrats.. Boy? Girl ? Any names? How's mum doing? Steve(spt) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adrian Brown Sent: 01 December 2008 23:29 To: sam-users@nvg.ntnu.no Subject: A little bit of news First off sorry ive been a little quiet on the uIP front, my first child was born in April and its been a little hectic around here. But finally I got an evening or two to sit down and type in a few more lines of z80 for the uIP TCP/IP stack for the Trinity board from Colin Piggot. As some of you may recall I had a simple ICMP echo ping replying so you could ping the Sam from a pc and it would reply. I added in ARP so it would correctly resolve IP to MAC etc for talking across the internet. Well at 23:01 this evening the Sam successfully made its first DNS lookup of a domain. I compiled it up with the string www.apbcomputerservices.co.uk and it happily posted off the request and got the reply back, after processing it it displayed www.apbcomputerservices.co.uk=58.d0.f7.4f - which is indeed the IP of my hosting server written in hex :D Today DNS... Tomorrow... THE WORLD :D APB Computer Services Ltd. Registered Address: 3 Springfield, Trevadlock, Congdons Shop, Launceston, Cornwall, PL15 7PW. Registration Number: 4942193. V.A.T. No: 826 0005 70 This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
Re: SAM Revival issue 22 out now!
Having just received a copy, obviously I have to say that the 3d demo is truly awesome. As is the rest of the magazine and disk. But it does make it apparent that the floppy drive in my Sam isn't long for this world. I have an external one too, so I should be fine - but is there any solution yet for an entirely solid state Sam? As I understand it, neither the Trinity nor the Atom attempt to look like a WD177x, so the ROM can't load DOS from them. Is there anything else I can do? Is there maybe a Trinity and a modified ROM that I can purchase, or maybe something else I haven't thought of? If not, is anyone working on anything in this respect? On Tue, Dec 30, 2008 at 9:43 AM, Colin Piggot qua...@clara.net wrote: Hi folks, Just a quick note to say that SAM Revival issue 22 is now out, and subscribers copies have been posted this morning. All the info on the issue and PayPal buy now options are up on my website at www.samcoupe.com All the best, Colin = Quazar : Hardware, Software, Spares and Repairs for the SAM Coupe 1995-2008 - Celebrating 14 Years of developing for the SAM Coupe Website: http://www.samcoupe.com/
Re: SAM Revival issue 22 out now!
How hard is it to obtain a copy of the modified ROM in the correct physical format and subsequently to install it? I'm a complete electronics dunce. Also, any thoughts on how hard it would be to put together a similar ROM for the Trinity? On Thu, Jan 8, 2009 at 1:15 PM, Steve Parry-Thomas morriga...@aol.com wrote: I use this as my default SAM setup, that's how the Atom Lite Pro-Dos (ALPD) came about. ( Thanks Edwin for the time spent on the ALPD hacks). It's a real treat to just swap the CF cards between Atom Lite and SIM Coupe. But remember the Atom Lite is not a hot swap system. Steve(spt). I have an Atom [Lite] card in the drive 2 slot, and use Edwin's modified ROM to boot directly from it. As a bonus, you can use the CF card with SimCoupe on your desktop machine to share all the same programs and data (well, once I've done a release with Lite support!). It's sometimes still be handy to have drive 1 as a working floppy, though not essential if you have access to a desktop PC for disk imaging. I'll see if I've got a spare SAM drive kicking around, as I rarely have 2 fitted anymore. Otherwise Colin can probably help with repair or replacement. Si
Re: SAM Revival issue 22 out now!
To my mind, this would add significantly to the value of the Trinity, and if you were to develop such a thing (presumably it'd just be however long it takes to modify the OS ROM, then existing Trinitys could be reflashed?) then I would definitely go on the pre-order list. In fact, I guess you'd just be able to offer the OS ROM as an upgrade (?), so I guess I could order a Trinity right now and get myself in order with whatever tiny number of discs I didn't long ago image while the drive is still working. While the Atom and that ROM would clearly solve my solid-state needs, it would be nice to throw some ethernet on in there while I'm spending the cash. On 8 Jan 2009, at 21:02, Colin Piggot wrote: Thomas wrote: Also, any thoughts on how hard it would be to put together a similar ROM for the Trinity? Simon wrote: Spare space in the ROM is fairly limited and Edwin spent a while shaving extra bytes of his AL detection and booting code. Still, with the Trinity being a single device on known ports, it might require less space Evening, Just sitting here thinking about about it, it could probably be done a lot simpler with the Trinity. For the Trinity, space in the ROM would only have to be found to fit in a very small routine to see if the Trinity is connected and then if it is load an extra chunk of code from the onboard 128K EEPROM into memory. It would then execute what it fetched from the EEPROM to load the full DOS into memory. Although, why not then just go the whole way and store the DOS in the 128K EEPROM to save having to fetch that from the SD card. From what I remember back when I was changing ROM3 for the Mayhem - removing the copyright message and coloured bars would possibly be all that's required to get enough room for the tiny chunk of code to fetch stuff from the EEPROM. Colin = Quazar : Hardware, Software, Spares and Repairs for the SAM Coupe 1995-2009 - Celebrating 15 Years of developing for the SAM Coupe Website: http://www.samcoupe.com/
B-DOS hard disk layout?
I'm just trying to put together a quick OS X tool for managing the 2 gb SD card that I'm using with my new and spiffy Trinity interface — I've been informed by Colin that the cards use the standard B-DOS layout, identical to the Atom, but I can't seem to find any documentation on that. Can anyone point me in the right direction? My sole observations to date from directly inspecting the SD card (via its /dev entry) is that disk images aren't track interleaved as DSK files are, and seem to start on 512-byte boundaries as you'd expect but not at any particularly obvious higher level boundaries. If I search for filenames that I know to be on disks then I can locate, extract and interleave DSK-style disk images by hand but that's not exactly a brilliant solution. The hex editor I'm using can't find the B-DOS record names anywhere (at least in ASCII format). I apologise if this information is somewhere obvious, but right now I really can't find it. There's a lot of stuff about accessing the storage through B-DOS, but that's not really very helpful for this problem. Oddly, Sim Coupe refuses to treat the card as though it were an Atom image (by setting /dev/[r]disk1s1 as the location of the Atom drive image as per the docs and the particular /dev entry my SD card ends up with). I'm not sure what to make of that at present.
Re: B-DOS hard disk layout?
Yep, I have Sam Revival 21 and have clocked the article on how the flat 32 bit address space is mapped to a traditional disk-style sector/ track/head layout. I noticed that 2 gb cards aren't officially supported, but that was the smallest size that I was able to obtain and seems to work fine, albeit without using all the space. Since grabbing 800 kb of data from the SD card then rearranging the tracks such as to interleave them produced a DSK file identical to a reference copy that I downloaded from the internet (for Fred 34, as it happens), I am working under the assumption that this isn't a problem — whether by luck or otherwise. I have a DSK image of Sam Revival 21's floppy, so will be able to extract the relevant Trinity B-DOS source and therefore do not imagine that figuring out how to map to/from B-DOS disk addressing and the flat address space will be a problem. However, unless I'm suffering some serious logic flaw, I will then still need to know the B-DOS disk layout. Sadly SamDisk is closed source and Sim Coupe doesn't directly deal with the structure as far as I can tell. Admittedly it had not occurred to me until this second that it may be hidden in comments in the B-DOS source (sadly one of the files that Edwin does not offer for download outside of a disk image). I hope to have access to a Windows PC later in the week (being currently unaware of any tools for managing disk image contents from OS X), if not then the SAMDOS format looks quite trivial so I guess I can just write my own thing. And then post again if the relevant information is not in there. On 8 Feb 2009, at 18:55, Colin Piggot wrote: Thomas Harte wrote: I'm just trying to put together a quick OS X tool for managing the 2gb SD card that I'm using with my new and spiffy Trinity interface - I've been informed by Colin that the cards use the standard B-DOS layout, identical to the Atom, but I can't seem to find any documentation on that. Can anyone point me in the right direction? The current patched B-DOS for Trinity (1.5t beta 4) only supports up to 1GB SD cards at the current time. I've not put in code for switching 2GB cards from 1024 byte sectors to 512 byte sectors hence why they are not supported. Certainly as far as the SAM is concerned, it is a typical B-DOS device. However, if you dump the whole card as a file it's structure and layout won't nessesarily be the same as a dumped HD image from the Atom. The patches I put into B-DOS give the MMC/SD card a fake geometry so B- DOS can work as if it's dealing with a HD with head, cylinder and sector values to save rewriting massive chunks of Edwin's original B-DOS code, and then there are a set of equations that then translate this back to a linear address within the SD card for when reading and writing take placed - with a different equation used depending on the flash card's size and multiplier values. All the changes are documented in SAM Revival 21 and the source code for the patched B-DOS is on that cover disk as well as the B-DOS disk with the Trinity. Colin = Quazar : Hardware, Software, Spares and Repairs for the SAM Coupe 1995-2009 - Celebrating 15 Years of developing for the SAM Coupe Website: http://www.samcoupe.com/
Re: B-DOS hard disk layout?
Or, presumably, I could grab the SD card content to my hard disk, switch all pairs of bytes and then use that in the emulator? I shall have to keep my eyes open for a 1 gb SD card since the 2 gb won't be formatted to the correct size from Sim Coupe's point of view even though it works fine on the Trinity — in any case, I imagine that once Trinity B-DOS is patched to support 2GB cards properly, I'll lose all my files. I definitely want to get a FUSE plug-in working so that I can just drag and drop from the Finder, but Sim Coupe is a more than adequate way to transfer my DSK files from the computer for now. Thanks for looking into it! On 10 Feb 2009, at 18:24, Simon Owen wrote: Earlier I wrote to Thomas Harte: I don't currently own a regular SD card, so I'm not able to try it myself. I'll see if I can pick one up in the next couple of days I managed to acquire a 1GB SD at lunchtime, so I've had a quick go. It uses normal byte ordering like Atom Lite, so you just need a version of SimCoupe that supports the Atom Lite in addition to original Atom. My 1GB card (SanDisk Ultra II) has 198400 sectors. Trinity BDOS reports Card size 3874, Multiplier 7(?) with 1240 records. SimCoupe and SamDisk both also show 1240 records, and it does work fine as expected. I can check in the AL changes if you want to build a new SimCoupe yourself, otherwise it might take a few days to sort out a binary. Si
Power supply making a buzzing noise
It's not too important, since I have a spare (albeit with the VHF video thingy missing), but my Sam's power supply has started making an increasingly loud buzzing noise when it is plugged in. Should I be alert that it is not long for this world and/or worried for my own safety?
Loss of colours
My next Sam physical hardware question — is there any reason why my Sam might find itself merging similar colours? Check out: http://members.allegro.cc/ThomasHarte/temp/Image(072).jpg That's how the first screen of Prince of Persia looks from both the SamCo Birthday disk and Blitz 8 (thought I'd check, since the birthday disk one is clearly an earlier version of the demo and, for all I knew, predates the game being completed). It's not a great photograph, but it does demonstrate the point. The walls on the TV are as they appear in that photo, a single solid blue. The effect is the same through both the aerial socket and RGB SCART, with or without the Trinity plugged in. I have no other hardware attached.
Re: Loss of colours
It seems likely to be the bright signal. Sam the Juggler runs with three shades of blue in the sky where there should be six, and the red square behind Sam's right arm is a solid red whereas in Sim Coupe it contains two separate red colours. Furthermore, the top of Sam's left leg blends in with the white square behind it, when it should be a touch darker. Assuming this diagnosis is correct, is there anything I can do that is likely to be easier and/or cheaper than simply obtaining a Sam with a functioning ASIC? On 19 Feb 2009, at 20:42, LCD wrote: Thomas Harte schrieb: My next Sam physical hardware question — is there any reason why my Sam might find itself merging similar colours? Check out: http://members.allegro.cc/ThomasHarte/temp/Image(072).jpg That's how the first screen of Prince of Persia looks from both the SamCo Birthday disk and Blitz 8 (thought I'd check, since the birthday disk one is clearly an earlier version of the demo and, for all I knew, predates the game being completed). It's not a great photograph, but it does demonstrate the point. The walls on the TV are as they appear in that photo, a single solid blue. The effect is the same through both the aerial socket and RGB SCART, with or without the Trinity plugged in. I have no other hardware attached. Maybe the Bright-Signal of your ASIC chip is gone, or there is a short circuit in the DAC for blue output.
Re: Fully detailed instruction timing breakdown?
Possibly a bit tediously realpolitik, but surely it'd be easiest just to write a routine that shoots out new palette values as quickly as possible for at least as long as the pixel area, set it to alternate between black and white, do a quick frame grab using a TV capture card and write a hasty program to thereby detect exactly which regions you need different bits of the palette to be consistent across? I assume that palette changes can take effect only outside of an 8 pixel block owing to the contended timings - that should eliinate any problems you might get as a result of the capture card being on a slightly different dot clock. Actually, it might be easier to see if you get the same result in Sim Coupe then just frame grab from there if so. On Mon, Feb 23, 2009 at 10:28 AM, Simon Owen simon.o...@simcoupe.org wrote: Simon Cooke wrote: I was wondering… does anyone have a fully-detailed breakdown of instruction timings for the SAM? Including at various points in the screen? It's hard to have a complete list for anything but the smallest instructions. For longer instructions it depends on how they fall inside, outside or across the contention boundaries, and which memory and I/O locations they access. Internal RAM accesses are rounded to 4T in the border area, or when the display is disabled. They're rounded to 8T when the ASIC is fetching data for the main screen, which begins an 8-pixel block before the main display area. Screen mode 1 adds additional bands of contention, with more 8T rounding (details on my website). External RAM accesses are always rounded to 4T, and ROM accesses are completely uncontended (no rounding). I/O accesses involving the ASIC (ports F8 and above) are rounded to 8T, other ports should be 4T rounded. The total timings for an instruction need to be built up one machine cycle at a time, with the appropriate memory and I/O rounding added, depending on where the raster is. It sounds messy, but it shouldn't be too bad since you'll only have a few fixed fragments of code for the palette changing. I can help you work out the instruction timing breakdown once you've decided on the code fragments to use... The idea is that it'd generate code to change the palette as the screen renders, and adjust the bitmap to get the closest it could to the original source. I was talking about that with someone a year or so ago (Edwin maybe?). Though it was only for a simplified version to change a few palette colours during the border area of each scanline. Your version would be much more effective, but is also far more complicated! Perhaps LCD would be interested in this too? His Retro-X application does a great job with the limited standard palette, so a dynamic palette should be even more impressive. Si
Re: SAM's 20th Birthday
I was only 9 years old, but I believe that I received an MGT Sam with a disk drive for £200 somewhere around October 1990. Is that possible? On Mon, Aug 3, 2009 at 9:03 PM, Andrew Collierand...@intensity.org.uk wrote: On 3 Aug 2009, at 20:23, Adrian Brown wrote: I remember selling my spectrum to part fund my sam and living without a computer for 5 months running up to the release of the sam before i could afford one :) Those were horrible days, but all worth it when i got the sam - even though it didnt have a disk drive, i could only aford the tape version. Defenders of the earth on tape- that was a painful load :) I don't remember precisely when I got mine - probably towards the end of 1990 since it was definitely after Sam Computers Ltd started up when you could get the Sam with a disk drive included for under £200, which I did. Eee, luxury, I can hear you cry - and maybe that's true, but I'll tell you the disk drive was not the world-changing first impression which tape owners might have you believe. You see, the instructions for the disk drive said that the first things you must do is to backup the boot disk - and, being the sort of nice boy who would read instructions and follow them, that's exactly what I started by doing. In fact there was even an option on the boot menu to do it; you would think this would run some semi-efficient disk copying routine? I later discovered that all it did was to run COPY * TO * and in the days before MasterDOS this involves swapping the floppy disks back and forth for every individual file on the disk. So there I am, dutifully swapping between one floppy disk and another floppy disk for what seemed like hours, wondering whether I was going to wear out the floppy disks eject button on the first day, and this was before I had even run Flash! or listened to the MGT anthem... Oddly enough, one of the first BASIC programs I wrote was a simple disk copier which used READ AT and WRITE AT to read half a disk at a time into memory and duplicate a disk in only two swaps. It wasn't fast, but it was way easier than SamCo's approved method at the time... Andrew -- http://www.intensity.org.uk/
Re: Hi - just checking
Am I replying to the correct thread? I don't know. But I've had the opposite experience to a bunch of people here, having become substantially more busy in my work than I was even just a few months ago, squeezing the SAM temporarily out. A version of my vector 3d-stuff-as-a-library-for-others was all but finished several months ago, I'll endeavour to get that out, though it still has the awkward limitation of doing rotations with Euler angles only — which may be less efficient and is certainly more limiting than special orthogonals or quaternions. I'm still thinking about smart ways to optimise the reverse face stuff. I need to get something hierarchical or otherwise group-related in there; checking every single face is obviously not the optimal way to proceed. I guess what I'm looking for is some sort of bin-type mapping to the surface of the unit sphere that allows all the points on a particular hemisphere to be isolated from the majority of the points on the opposite hemisphere. Or, you know, something at least a lot like a sphere. Though I'm not sure any sort of lookup into something a lot like a sphere would help much as it'd need to be indexed by a three-tuple. I guess a good broad sweep would be to mark each face according to the visibility of the faces of a bounding box — if a face on the real model points away from the face on the bounding box then it definitely can't be visible if the box face is. Or something like that. I'm going to stop thinking aloud now... On Tue, Aug 4, 2009 at 10:22 AM, Steve Parry-Thomasmorriga...@aol.com wrote: I guess when the clocks go back in October SAM users will hibernate over the winter until next August! From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of Ian Spencer Sent: 04 August 2009 08:04 To: sam-users@nvg.ntnu.no Subject: Re: Hi - just checking Wow, I just sent the checking mail to see whether something was wrong with my subscription to the group and it seems it was like poking a stick into a hornets nest (in a positive sort of way) - over 40 mails in the last few days on the group. It's just great to see everyone is alive and kicking out there. Ian - Original Message - From: Ian Spencer To: sam-users@nvg.ntnu.no Sent: Friday, July 31, 2009 4:10 PM Subject: Hi - just checking Not heard anything on the group for quite a while so just thought I would send a 'test' to check it's not me that's got a problem and say hi to everyone. I know you've all taken your Sam's to the beach and so no activity on the group. Ian
Re: Hi - just checking
That's not entirely true. Matrices are numerically unstable, so the cost of ensuring they remain orthonormal when applying consecutive local transforms in a game such as Elite is substantially greater than the cost of ensuring that a quaternion remains of unit length. I make it 8 multiplies, 3 adds, 1 square root and 1 divide to fix up numerical error in a quaternion. Conversely, I get 36 multiplies, 21 adds, 3 square roots and 3 divides to fix up an orthonormal matrix. Quaternion to matrix is 10 multiplies, 6 shifts and 14 adds. So the way I calculate it, you can fix a quaternion and convert it into a matrix in less than you can fix up a matrix. Furthermore, quaternion composition is 16 multiplies and 12 adds, whereas matrix composition (with assumptions about the bottom row of a 4x4) is, ummm, at least 36 multiplies and 18 adds. And that's with the translation component not completely factored in (I'm reading actual code off screen and have optimised the translation out of this particular batch). Elite is also a perfect example of when Euler's aren't fine, even if they didn't produce Gimbal lock, as all rotation is around local axes. And besides that, Euler angles always have to be converted to some other form before they can be applied to arbitrary geometry. Matrices require no further transforms. On Wed, Aug 5, 2009 at 2:12 AM, Simon Cookesi...@popcornfilms.com wrote: You only really need quaternions if you're doing animation or interpolation. If you can live with the gimble lock, euler's fine. -Original Message- From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of Thomas Harte Sent: Tuesday, August 04, 2009 10:05 AM To: sam-users@nvg.ntnu.no Subject: Re: Hi - just checking Am I replying to the correct thread? I don't know. But I've had the opposite experience to a bunch of people here, having become substantially more busy in my work than I was even just a few months ago, squeezing the SAM temporarily out. A version of my vector 3d-stuff-as-a-library-for-others was all but finished several months ago, I'll endeavour to get that out, though it still has the awkward limitation of doing rotations with Euler angles only - which may be less efficient and is certainly more limiting than special orthogonals or quaternions. I'm still thinking about smart ways to optimise the reverse face stuff. I need to get something hierarchical or otherwise group-related in there; checking every single face is obviously not the optimal way to proceed. I guess what I'm looking for is some sort of bin-type mapping to the surface of the unit sphere that allows all the points on a particular hemisphere to be isolated from the majority of the points on the opposite hemisphere. Or, you know, something at least a lot like a sphere. Though I'm not sure any sort of lookup into something a lot like a sphere would help much as it'd need to be indexed by a three-tuple. I guess a good broad sweep would be to mark each face according to the visibility of the faces of a bounding box - if a face on the real model points away from the face on the bounding box then it definitely can't be visible if the box face is. Or something like that. I'm going to stop thinking aloud now... On Tue, Aug 4, 2009 at 10:22 AM, Steve Parry-Thomasmorriga...@aol.com wrote: I guess when the clocks go back in October SAM users will hibernate over the winter until next August! From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of Ian Spencer Sent: 04 August 2009 08:04 To: sam-users@nvg.ntnu.no Subject: Re: Hi - just checking Wow, I just sent the checking mail to see whether something was wrong with my subscription to the group and it seems it was like poking a stick into a hornets nest (in a positive sort of way) - over 40 mails in the last few days on the group. It's just great to see everyone is alive and kicking out there. Ian - Original Message - From: Ian Spencer To: sam-users@nvg.ntnu.no Sent: Friday, July 31, 2009 4:10 PM Subject: Hi - just checking Not heard anything on the group for quite a while so just thought I would send a 'test' to check it's not me that's got a problem and say hi to everyone. I know you've all taken your Sam's to the beach and so no activity on the group. Ian
Re: Hi - just checking
Oh, I'm currently using 2.14 fixed point for matrix components (engine goes Eulers - matrix, apply that) if that helps the discussion of the level of nuisance caused by numerical errors. Earlier versions of the code, including I think the version last provided on Sam Revival, used 8.8 fixed point throughout but that produced some visible precision issues. 2.14 isn't exactly perfect, but it's as good as things are going to get without a major speed tradeoff. The 2.14 is used only for matrix generation and composition (since objects are assumed to be positioned under the influence of exactly two matrices in my code — a camera matrix and an object matrix), it's rendered down to 8.8 for geometry transformation. On Wed, Aug 5, 2009 at 1:14 PM, Thomas Hartetomh.retros...@gmail.com wrote: That's not entirely true. Matrices are numerically unstable, so the cost of ensuring they remain orthonormal when applying consecutive local transforms in a game such as Elite is substantially greater than the cost of ensuring that a quaternion remains of unit length. I make it 8 multiplies, 3 adds, 1 square root and 1 divide to fix up numerical error in a quaternion. Conversely, I get 36 multiplies, 21 adds, 3 square roots and 3 divides to fix up an orthonormal matrix. Quaternion to matrix is 10 multiplies, 6 shifts and 14 adds. So the way I calculate it, you can fix a quaternion and convert it into a matrix in less than you can fix up a matrix. Furthermore, quaternion composition is 16 multiplies and 12 adds, whereas matrix composition (with assumptions about the bottom row of a 4x4) is, ummm, at least 36 multiplies and 18 adds. And that's with the translation component not completely factored in (I'm reading actual code off screen and have optimised the translation out of this particular batch). Elite is also a perfect example of when Euler's aren't fine, even if they didn't produce Gimbal lock, as all rotation is around local axes. And besides that, Euler angles always have to be converted to some other form before they can be applied to arbitrary geometry. Matrices require no further transforms. On Wed, Aug 5, 2009 at 2:12 AM, Simon Cookesi...@popcornfilms.com wrote: You only really need quaternions if you're doing animation or interpolation. If you can live with the gimble lock, euler's fine. -Original Message- From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of Thomas Harte Sent: Tuesday, August 04, 2009 10:05 AM To: sam-users@nvg.ntnu.no Subject: Re: Hi - just checking Am I replying to the correct thread? I don't know. But I've had the opposite experience to a bunch of people here, having become substantially more busy in my work than I was even just a few months ago, squeezing the SAM temporarily out. A version of my vector 3d-stuff-as-a-library-for-others was all but finished several months ago, I'll endeavour to get that out, though it still has the awkward limitation of doing rotations with Euler angles only - which may be less efficient and is certainly more limiting than special orthogonals or quaternions. I'm still thinking about smart ways to optimise the reverse face stuff. I need to get something hierarchical or otherwise group-related in there; checking every single face is obviously not the optimal way to proceed. I guess what I'm looking for is some sort of bin-type mapping to the surface of the unit sphere that allows all the points on a particular hemisphere to be isolated from the majority of the points on the opposite hemisphere. Or, you know, something at least a lot like a sphere. Though I'm not sure any sort of lookup into something a lot like a sphere would help much as it'd need to be indexed by a three-tuple. I guess a good broad sweep would be to mark each face according to the visibility of the faces of a bounding box - if a face on the real model points away from the face on the bounding box then it definitely can't be visible if the box face is. Or something like that. I'm going to stop thinking aloud now... On Tue, Aug 4, 2009 at 10:22 AM, Steve Parry-Thomasmorriga...@aol.com wrote: I guess when the clocks go back in October SAM users will hibernate over the winter until next August! From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of Ian Spencer Sent: 04 August 2009 08:04 To: sam-users@nvg.ntnu.no Subject: Re: Hi - just checking Wow, I just sent the checking mail to see whether something was wrong with my subscription to the group and it seems it was like poking a stick into a hornets nest (in a positive sort of way) - over 40 mails in the last few days on the group. It's just great to see everyone is alive and kicking out there. Ian - Original Message - From: Ian Spencer To: sam-users@nvg.ntnu.no Sent: Friday, July 31, 2009 4:10 PM Subject: Hi - just checking Not heard anything on the group for quite
Re: Hi - just checking
You mean the Psion one? No idea, as I've never used it or explicitly disassembled anything z80 related. I've entered the z80 assembly fold from the direction of writing emulators. I'd guess that if it's not intended to be particularly realtime then quite possibly they're using the floating point formats supported natively by the Spectrum ROM? It'd save a lot of code and solve a lot of issues, and while being far too slow for realtime it'd probably be fast enough for a rendering-type application. Just guessing, of course. On Wed, Aug 5, 2009 at 1:18 PM, Roger Jowettrogerjow...@gmail.com wrote: what does vu3d use? On 05/08/2009, Thomas Harte tomh.retros...@gmail.com wrote: That's not entirely true. Matrices are numerically unstable, so the cost of ensuring they remain orthonormal when applying consecutive local transforms in a game such as Elite is substantially greater than the cost of ensuring that a quaternion remains of unit length. I make it 8 multiplies, 3 adds, 1 square root and 1 divide to fix up numerical error in a quaternion. Conversely, I get 36 multiplies, 21 adds, 3 square roots and 3 divides to fix up an orthonormal matrix. Quaternion to matrix is 10 multiplies, 6 shifts and 14 adds. So the way I calculate it, you can fix a quaternion and convert it into a matrix in less than you can fix up a matrix. Furthermore, quaternion composition is 16 multiplies and 12 adds, whereas matrix composition (with assumptions about the bottom row of a 4x4) is, ummm, at least 36 multiplies and 18 adds. And that's with the translation component not completely factored in (I'm reading actual code off screen and have optimised the translation out of this particular batch). Elite is also a perfect example of when Euler's aren't fine, even if they didn't produce Gimbal lock, as all rotation is around local axes. And besides that, Euler angles always have to be converted to some other form before they can be applied to arbitrary geometry. Matrices require no further transforms. On Wed, Aug 5, 2009 at 2:12 AM, Simon Cookesi...@popcornfilms.com wrote: You only really need quaternions if you're doing animation or interpolation. If you can live with the gimble lock, euler's fine. -Original Message- From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of Thomas Harte Sent: Tuesday, August 04, 2009 10:05 AM To: sam-users@nvg.ntnu.no Subject: Re: Hi - just checking Am I replying to the correct thread? I don't know. But I've had the opposite experience to a bunch of people here, having become substantially more busy in my work than I was even just a few months ago, squeezing the SAM temporarily out. A version of my vector 3d-stuff-as-a-library-for-others was all but finished several months ago, I'll endeavour to get that out, though it still has the awkward limitation of doing rotations with Euler angles only - which may be less efficient and is certainly more limiting than special orthogonals or quaternions. I'm still thinking about smart ways to optimise the reverse face stuff. I need to get something hierarchical or otherwise group-related in there; checking every single face is obviously not the optimal way to proceed. I guess what I'm looking for is some sort of bin-type mapping to the surface of the unit sphere that allows all the points on a particular hemisphere to be isolated from the majority of the points on the opposite hemisphere. Or, you know, something at least a lot like a sphere. Though I'm not sure any sort of lookup into something a lot like a sphere would help much as it'd need to be indexed by a three-tuple. I guess a good broad sweep would be to mark each face according to the visibility of the faces of a bounding box - if a face on the real model points away from the face on the bounding box then it definitely can't be visible if the box face is. Or something like that. I'm going to stop thinking aloud now... On Tue, Aug 4, 2009 at 10:22 AM, Steve Parry-Thomasmorriga...@aol.com wrote: I guess when the clocks go back in October SAM users will hibernate over the winter until next August! From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of Ian Spencer Sent: 04 August 2009 08:04 To: sam-users@nvg.ntnu.no Subject: Re: Hi - just checking Wow, I just sent the checking mail to see whether something was wrong with my subscription to the group and it seems it was like poking a stick into a hornets nest (in a positive sort of way) - over 40 mails in the last few days on the group. It's just great to see everyone is alive and kicking out there. Ian - Original Message - From: Ian Spencer To: sam-users@nvg.ntnu.no Sent: Friday, July 31, 2009 4:10 PM Subject: Hi - just checking Not heard anything on the group for quite a while
Re: Hi - just checking
Oh, sorry, I think I missed the point of your question. My guess would be that it uses matrices internally, as they're a popular mathematical construct in a variety of fields but quaternions having been seriously out of fashion for at least a century. I have a degree in Maths Computer Science but don't recall meeting them even once during my studies — though a joint honours degree does necessarily end up reducing your exposure to either subject individually. Also, my guess is that the sort of literature related to computer graphics that is now extremely easy to access thanks to the web would have been really quite hard to access during the 1980s. It's like a hindsight thing. We're perched here at least two decades after computer graphics started to break out of academia and into widescale usage in consumer products, so we benefit from historical perspective and the entire body of knowledge is now much more accessible. On Wed, Aug 5, 2009 at 1:23 PM, Thomas Hartetomh.retros...@gmail.com wrote: You mean the Psion one? No idea, as I've never used it or explicitly disassembled anything z80 related. I've entered the z80 assembly fold from the direction of writing emulators. I'd guess that if it's not intended to be particularly realtime then quite possibly they're using the floating point formats supported natively by the Spectrum ROM? It'd save a lot of code and solve a lot of issues, and while being far too slow for realtime it'd probably be fast enough for a rendering-type application. Just guessing, of course. On Wed, Aug 5, 2009 at 1:18 PM, Roger Jowettrogerjow...@gmail.com wrote: what does vu3d use? On 05/08/2009, Thomas Harte tomh.retros...@gmail.com wrote: That's not entirely true. Matrices are numerically unstable, so the cost of ensuring they remain orthonormal when applying consecutive local transforms in a game such as Elite is substantially greater than the cost of ensuring that a quaternion remains of unit length. I make it 8 multiplies, 3 adds, 1 square root and 1 divide to fix up numerical error in a quaternion. Conversely, I get 36 multiplies, 21 adds, 3 square roots and 3 divides to fix up an orthonormal matrix. Quaternion to matrix is 10 multiplies, 6 shifts and 14 adds. So the way I calculate it, you can fix a quaternion and convert it into a matrix in less than you can fix up a matrix. Furthermore, quaternion composition is 16 multiplies and 12 adds, whereas matrix composition (with assumptions about the bottom row of a 4x4) is, ummm, at least 36 multiplies and 18 adds. And that's with the translation component not completely factored in (I'm reading actual code off screen and have optimised the translation out of this particular batch). Elite is also a perfect example of when Euler's aren't fine, even if they didn't produce Gimbal lock, as all rotation is around local axes. And besides that, Euler angles always have to be converted to some other form before they can be applied to arbitrary geometry. Matrices require no further transforms. On Wed, Aug 5, 2009 at 2:12 AM, Simon Cookesi...@popcornfilms.com wrote: You only really need quaternions if you're doing animation or interpolation. If you can live with the gimble lock, euler's fine. -Original Message- From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of Thomas Harte Sent: Tuesday, August 04, 2009 10:05 AM To: sam-users@nvg.ntnu.no Subject: Re: Hi - just checking Am I replying to the correct thread? I don't know. But I've had the opposite experience to a bunch of people here, having become substantially more busy in my work than I was even just a few months ago, squeezing the SAM temporarily out. A version of my vector 3d-stuff-as-a-library-for-others was all but finished several months ago, I'll endeavour to get that out, though it still has the awkward limitation of doing rotations with Euler angles only - which may be less efficient and is certainly more limiting than special orthogonals or quaternions. I'm still thinking about smart ways to optimise the reverse face stuff. I need to get something hierarchical or otherwise group-related in there; checking every single face is obviously not the optimal way to proceed. I guess what I'm looking for is some sort of bin-type mapping to the surface of the unit sphere that allows all the points on a particular hemisphere to be isolated from the majority of the points on the opposite hemisphere. Or, you know, something at least a lot like a sphere. Though I'm not sure any sort of lookup into something a lot like a sphere would help much as it'd need to be indexed by a three-tuple. I guess a good broad sweep would be to mark each face according to the visibility of the faces of a bounding box - if a face on the real model points away from the face on the bounding box then it definitely can't be visible if the box face is. Or something
Re: Hi - just checking
They're in some format or another that I don't recall offhand, but is lined up so that a full circle is a nice round binary number for the obvious range fixing optimisation. But it's not just a quick sin/cos table lookup unless you're rotating around one axis only. See, e.g. http://www.manpagez.com/man/3/glRotatef/ (the man page for glRotatef) — clearly there's a lot more going on there than table lookups. Of course, I am taking note of coherences. If the angles associated with an object do not change from one frame to the next, the source matrix is not recalculated. This optimisation postdates the version of my code that has already appeared on Sam Revival, but predates the next version (which is a better optimised version of the code shown in my video http://www.youtube.com/watch?v=j0xN_Mi3B_I) As I've posted to this list in the past, I use something vaguely like SIMD to multiply a 2d vector by a scalar — the relevant part of the scalar sits in the accumulator and is shifted there to make the add/don't add decision in the standard binary multiplication formula, meanwhile the 2d vector sits with the work going in for one component occupying BC, DE and HL, the work for the other occupying BC', DE' and HL'. Hence I get a substantial saving on multiplying the two vector components by the scalar separately. Naturally, I have a classic y = f((x^2)/4) table for the limited range multiplications (related to the maximum size an individual object may be). I assume your point about not accumulating transformations in matrices effectively means that you agree that quaternions are useful beyond interpolation and animation (which I'm interpreting quite narrowly to be the traditional skeletal type, not broadly to be any old moving image). Anyway, hopefully I'll be able to get myself in gear for a source release at some point in the near future, then you can rip it apart. It's all geared up to be trivial for other (assembler) coders to use to produce their own programs, handling triple buffering and frame rate compensation with very limited need for work on the part of the programmer (which neatly means that all my code scales really well from a normal Sam to a Mayhem or otherwise accelerated machine), etc. I tidied most of it up for a release quite a while ago but decided to switch to Jam rather than sticking on pyz80 because a lot of stuff would be substantially more compact and more readable with proper macro support. I also would much rather that the demo was seen first on Sam Revival rather than on the internet, both as a pathetic attempt to support the publication and because it looks much better on a real television. Never found time to convert it though, so it'll be a pyz80 release. Actually, the demo on the previous Sam Revival was explicitly flagged as PD, so I'll upload a DSK of that demo somewhere once the next edition is out. I think I mentioned every Sam program I've written in the SR article; you can see most of them very briefly in http://www.youtube.com/watch?v=kr_Lz98qVjEfeature=channel_page On Wed, Aug 5, 2009 at 10:16 PM, Simon Cookesi...@popcornfilms.com wrote: Hmmm... what form are you using your Eulers in? If it's radians, it's not too bad - just a quick sin/cos table lookup. And you only need to do it once per object if it's a simple rigid body. The trick with making matrices numerically stable is that you don't ever want to do a stepwise transform on an object - you regenerate the matrix from scratch each time. (This is one of those things you never really see in practice; most engines split out the rotational transforms and keep them separate, using either an axis-angle representation, quaternions, or in some bad cases, euler angles [this is what Unreal uses btw]. That way, you keep fidelity - or at the very least, you don't care too much about inaccuracies as they come in - you can just ignore them if your object is rotated a little off; it's not a culumlative error). Assuming no scaling or shear, just rotation and translation, your translation is the rightmost column of numbers in the matrix. If all of your objects are pre-scaled in memory to the right size, all you have to do is apply the rotation and translation in order to each of the points. Screen-space projection is a little more difficult, but that one you can precalc all the divides in. On machines without SIMD or dedicated 3D instructions (such as the SAM), it's nearly always best to break out the matrix into individual linear equations, take the common pieces and only calculate them once, and then operate on them that way. -- Simon Cooke Director of Engineering / Business Developer, X-RAY KID STUDIOS - www.x-raykid.com Founder, Popcorn Films - www.popcornfilms.com Cell: 206 250 7892 XBOX Live GamerTag: Spec Tec -Original Message- From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of Thomas Harte Sent: Wednesday, August 05, 2009 5:14 AM To: sam-users
Re: Hello to the Sam community!
Didn't the entirety of Take That, with Robbie, once play Bomberman on a single Amiga on Gamesmaster? That must have been at least three on the keyboard, assuming I didn't make it up. Ant Attack would actually work really well on the Sam. I've never seen the original code, but by my reckoning it's a forward raycast into a triangle grid - Ant Attack having only one size and look of block. So it'd be really cheap to compute the minimal set of pixels that must be replotted to perform a scroll while leaving the same coloured blocks alone. Don't think it's a 16kb game though - I stole the map for a PC game once I think that may have been 16kb on its own. On Tuesday, August 4, 2009, the_wub ! the...@gmail.com wrote: wow thanks for the link, his site is a hoot :D and I was definately wrong about it being 16k :)
Re: Hello to the Sam community!
Could the block drawing routine use bitmap data? I was imagining itty
bitty brick and stone wall effects and different textured floors.
Yep, yep, should be fine. Having quickly searched, I wrote a forward
ray casting for Ant Attack thingy in C with Allegro a few years ago,
that just loaded an image of the base brick and chopped it up at
runtime. Casting into a map in exactly the memory layout as Ant
Attack, the relevant C code was less than 100 lines, so I hope I'll be
forgiven for regurgitating it at the bottom of this post.
Most of the Allegro function names are self explanatory, I hope. Per
file dates, I last worked on this during February 2002. A screenshot
is at http://members.allegro.cc/ThomasHarte/thumbs/AntAttack.png. It
seems to cast out from diamonds and run a single loop searching to
fill both the left triangle and the right triangle, not sure if it'd
be more efficient to break it up into two...
#define GetByte(x, y) ( ((x) -64) || ((y) -64) || ((x) 63) ||
((y) 63) ) ? 0 : map[((x+64) 7) | (y+64)]
void LaunchRay(int mapx, int mapy, int x, int y)
{
int mask = 0x20;
int byte1, byte2, byte3, byte4;
int leftempty = 1, rightempty = 1;
byte4 = GetByte(mapx, mapy);
while(mask (leftempty || rightempty))
{
byte1 = byte4;
byte2 = GetByte(mapx + LeftX, mapy + LeftY); //left one
byte3 = GetByte(mapx + DownX, mapy + DownY); //up one
mapx += LeftX + DownX;
mapy += LeftY + DownY;
byte4 = GetByte(mapx, mapy); //left up one
if(leftempty)
{
if(byte1mask)
{
draw_sprite(back, ul, x, y);
leftempty = 0;
}
else
{
if(byte2mask)
{
draw_sprite(back, mr, x, y);
leftempty = 0;
}
else
if(byte4mask)
{
draw_sprite(back, bl, x, y);
leftempty = 0;
}
}
}
if(rightempty)
{
if(byte1mask)
{
draw_sprite(back, ur, x+left-w, y);
rightempty = 0;
}
else
{
if(byte3mask)
{
draw_sprite(back, ml, x+left-w, y);
rightempty = 0;
}
else
if(byte4mask)
{
draw_sprite(back, br,
x+left-w, y);
rightempty = 0;
}
}
}
mask = 1;
}
if(leftempty byte4)
draw_sprite(back, shadowl, x, y);
if(rightempty byte4)
draw_sprite(back, shadowr, x+left-w, y);
}
void DrawMap(int offx, int offy)
{
int x, y, mapx, mapy;
clear_to_color(back, 72);
for(y = -(back-h 1); y back-h; y += left-h)
{
mapx = offx;
mapy = offy;
for(x = -(back-w 1); x back-w; x += (left-w 1))
{
LaunchRay(mapx, mapy, x, y);
LaunchRay(mapx-RightVector[1], mapy+RightVector[0],
x-left-w,
y+(left-h 1));
mapx += RightX + DownX;
mapy += RightY + DownY;
}
offx += RightX + UpX;
offy += RightY + UpY;
}
}
Re: Hello to the Sam community!
That's just the method I made up, I've no idea if it's how Ant Attack does it and it might well not fit with the Spectrum code at all. You have been warned! On Thu, Aug 6, 2009 at 5:44 PM, the_wub !the...@gmail.com wrote: crikey, that's very cool Thomas! maybe it's time for me to go find a disassembly howto..
(i) counting frames; (ii) emulators in general
Completely unrelated questions, but: (1) if I disable interrupts temporarily so that I can use the stack pointer for pixel plotting, is there any reliable way to spot afterwards if I've missed an end-of-display interrupt? I'm vaguely aware that there's a current scanline hardware counter somewhere — does that count actual PAL lines or only lines with pixels on them? And how long does the end-of-display interrupt signal last? My memory is saying 24 cycles, but I'm not sure why. I guess since we're on a system with no explicit interrupt acknowledgments, it's going to be something tiny? (2) over in Acornland we're currently discussing a remote debugging protocol, the primary purpose of which is to allow an emulator to emulate while a separate debugger connects to the emulator and tracks/adjusts state, etc. Currently the thinking is to go all modern and JSON + HTTPy about it (so you could even write a debugger in Javascript if you wanted, we're not dependant on any system-specific inter-process communications and the sort of languages you'd want to write a debugger in already know how to do most of the communication tasks), but I wondered if anybody here is aware of any existing emulators or standards that implement anything like that?
Re: Micro Men
Almost the entire first half hour was set before I was born! I enjoyed it though, even with the slightly weird ending — we're meant to believe that Microsoft, Compaq and HP got a major leg up just because Sir Clive and Chris Curry fell out? And was Sir Clive really that mean? On Sat, Oct 10, 2009 at 12:31 AM, nev young pasiphae1...@yahoo.co.uk wrote: Dan Dooré wrote: Stefan Drissen wrote: Excellent, that was most enjoyable – thanks for the heads up! The old days eh… J Just watched it off the DVR - it was great to relive the whole Sinclair-Acorn thing whilst not being an excited 12 year old :-) I watched it last night. it was great to relive the whole Sinclair-Acorn thing whilst not having to take the kids to school and pay the mortgage. :-) -- Nev (feeling far too old)
Re: Micro Men
Oh, I don't know. Surely Sinclair's model works only if you can establish yourself as the supplier of a proprietary computer aimed at the price conscious end of the market? I don't see how that could compete once a growing body of manufacturers were transferring to a PC-style open architecture. At some point economies of scale amongst the open people outweigh whatever economies you can achieve with a custom design and there's no way back from there. And ARM Holdings are still in Cambridge. On Sat, Oct 10, 2009 at 8:27 PM, nev young pasiphae1...@yahoo.co.uk wrote: Thomas Harte wrote: Almost the entire first half hour was set before I was born! I enjoyed it though, even with the slightly weird ending — we're meant to believe that Microsoft, Compaq and HP got a major leg up just because Sir Clive and Chris Curry fell out? And was Sir Clive really that mean? If CS and CC hadn't broken the UK computing industry I do believe that things would have been different. By how much and for how long is any body's guess. From what I remember the underhandedness of the BBC tendering was far worse than in the TV show. From what I hear, from within mensa, CS was (is) rather a control freak and _must_ have things his own way. That doesn't in any way diminish his visions and what he did. -- Nev
Bresenham's run-slice: any good in practice?
I'm working on a proper, robust and fast polygon filler*, as well as always looking to improve my line drawer, and have recently discovered Bresenham's alternative run-slice algorithm, via a Michael Abrash article published in Dr Dobbs in November '92. It switches you from making a decision every pixel (eg, stepping along x, deciding whether to make an adjustment in y after every pixel) to make a decision at the end of every slice (so if you were drawing a line 256 pixels wide and 2 pixels high, the first 128 pixels would be one slice that you knew the length of before drawing, the next 128 would be another slice; the length of every slice in a line varies by no more than 1 pixel so that's the decision) at the cost of an 8bit by 8bit integer divide with remainder outside the loop. This is explicitly still error tracking and proper integer arithmetic ala per-pixel Bresenham, there are no fractional parts. This isn't DDA in fixed point (which would be a much more than 8bit by 8bit integer divide) or anything like that. http://www.gamedev.net/reference/articles/article386.asp seems to be a facsimile of the article, albeit with the figures and listings missing somewhere. The way I see it, dividing costs less per bit than Bresenham does per pixel (using, e.g. those restoring divide as demonstrated at http://baze.au.com/misc/z80bits.html), so this could start costing less even on very small lines. It'll almost definitely cost less for polygon filling since you mainly want to know x intercept per scanline, so I can switch between regular Bresenham and run slice depending on the edge slope. With a 1/2 offset on the initial run of the slicing algorithm (so I'm picking the centre pixel for every slice), my C tests imply a great result with all the features you'd like (adjacent polygons always exactly meet up, the switch from per-pixel to run-slice isn't visible). That all said, I know I'm often hopelessly optimistic about these things. Has anyone with more experience looked into and/or implemented run-slice line drawing? * the one I used for my youtube videos leaves the occasional empty pixel between adjacent polygons, is limited to triangles and uses costly fixed-point division for every single edge. So: lots and lots of unnecessary 16bit divides.
Getting back into z80 programming (code included)
Having prototyped my new polygon filler to my satisfaction in C, today I've been converting it to assembler. With the iPhone stuff and an Acorn Electron project I've been working on, I haven't done any z80 in far too long and am not particularly optimistic that I'm writing good stuff. Actually, it strikes me that I've never really shown any z80 code to anyone, so maybe I'm just not great in general. Below is most of my new polygon filler. It's incomplete, but only in relatively minor ways — the scan converter handles edges where x increases only (obviously x decreases will be the same code with subs and decs rather than adds and incs, thought I'd leave that until I'm more confident in the stuff overall) and chucks pixels on the screen to show scanline ends rather than drawing an actual scanline of pixels (for which I'll be subverting SP per the usual sort of stuff). When calculating y intercepts it breaks down to either traditional Bresenham for lines that change in y more than in x or run-slice Bresenham for lines that change in x more than in y. Part of the reasoning for that is that it gives me something to compare the speeds of the two approaches. If run-slice does seem to be faster than standard for lines above a certain length (probably 9 or 10 pixels?) as I suspect, then obviously I'll use it for both. Anyway, if some of you z80 experts could have a quick look and tell me if I'm making any obvious style errors or otherwise missing obvious optimisations — even if only on a peephole level — I'd be infinitely grateful. Sorry if the comments are occasionally a bit opaque; some of them just document which registers are holding which variables from the original C. Thanks in advance! ; ; DrawPoly - draws a filled polygon using A vertices, in two arrays ; with x positions starting at (H:0) and y positions at (H+1:0) ; ; clobbers: af, bc, de, hl, af', bc', de', hl' ; DS ALIGN 256 LEFTTAB: ds 256 RIGHTTTAB: ds 256 NUMVERTS: db 0 VERTEXPOINTER: dw 0 STARTY: db 0 ENDY: db 0 DrawPoly: ; store stuff ld (VERTEXPOINTER), hl ld (NUMVERTS), a inc h ld e, a ld d, a ; use b to store current highest vertex pointer, c to store value ld l, 0 ld b, 0 ld c, (hl) ; get highest vertex pointer to b @highloop: inc l ; look at next y value ; check if look is over yet, exit if so dec d jr z, @+highloopdone ld a, (hl) ; load new y value cp c; compare to current highest jr nc, @-highloop ; don't do anything if it is lower ld b, l ld c, a jr @-highloop @highloopdone: ; highest value is now in c ld a, c ld (ENDY), a ; use c to store current lowest vertex pointer, d to store value ld l, 0 ld c, 0 ld d, (hl) ; get highest vertex pointer to c @lowloop: inc l ; look at next y value ; check if loop is over yet, exit if so dec e jr z, @+lowloopdone ld a, (hl) cp d jr c, @-lowloop ld c, l ld d, a jr @-lowloop @lowloopdone: ; highest value is now in d ld a, d ld (STARTY), a push bc ; b = current vertex, c = target ld hl, RIGHTTTAB @leftloop: ld a, b cp c jr z, @+leftloopdone dec a jp p, @+noreload ld a, (NUMVERTS) dec a @noreload: call @+PushToArray ld b, a jr @-leftloop @leftloopdone: pop bc ld hl, LEFTTAB ld d, (NUMVERTS) @rightloop: ld a, b cp c jr z, @+rightloopdone inc a cp d jr nz, @+noreload xor a @noreload: call @+PushToArray ld b, a jr @-rightloop @rightloopdone: ; ; page in the screen, for drawing ; LD C, HMPR IN a, (C) push af ld a, (rampage) OUT (C), a ld h, LEFTTAB 8 ld a, (ENDY) ld l, a ld a, (STARTY) sub l ld b, a @plotloop: ; left pixel ld a, (hl) inc h ; right pixel ld c, (hl) inc l dec h ld d, l ld e, a srl d rr e jr nc, @+rpx ld a, 0x0f
Re: Getting back into z80 programming (code included)
Oh, yeah, the plotloop is a complete placeholder, just so I can compare output to the C prototype. That said, I'd done exactly the same thing on scf versus set 7,d in my line drawing code (don't worry: just once, outside the loop). I must find time to finish documenting my vector drawing code as I'm sure that would only benefit from being seen by somebody other than me. The screen's at 32768 because I have multiplication tables occupying the highest and lowest 2kb of RAM. It's the usual squared and divided by 4 stuff, so by using that positioning I can do the relevant 16bit addition and subtraction in HL and then read the result directly from RAM without any further computation. On Sat, Oct 24, 2009 at 8:43 PM, Chris Pile chris.p...@blueyonder.co.uk wrote: Just a quick glimps of the code shows you can save 8-clocks every itteration of your plotloop by getting rid of the SET 7,D instructions and putting a SCF before a RR D instruction. Replacing the SRL D's with RR D's. But as you're not likely to be using this particular plotloop in the final article it probably doesn't matter too much! That said, using SCF / RR D instead of SRL D / SET 7,D is something worth remembering for later! Better still, keep your screens at address 0 and do away with the SCF's altogether. Rearranging your registers so that you don't need to keep calculating the screen address is always a good optimisation... But I take it you're going to use the stack to shove the scanlines on-screen? Which is even better!! I've always been a big fan of using the stack!! :-)) Chris. @plotloop: ; left pixel ld a, (hl) inc h ; right pixel ld c, (hl) inc l dec h ld d, l ld e, a srl d rr e jr nc, @+rpx ld a, 0x0f jr @+pxd @rpx: ld a, 0xf0 @pxd: set 7, d ld (de), a ld d, l ld e, c srl d rr e jr nc, @+rpx ld a, 0x0e jr @+pxd @rpx: ld a, 0xe0 @pxd: set 7, d ld (de), a djnz @-plotloop
Re: Getting back into z80 programming (code included)
One trick I almost always use, is instead of: [...] Oh, yes, smart move! I'm pretty sure I had at least one copy of Electron User that thought this technique so magnificent that it got a front page mention as discover extra registers or something like that. By the way: ld d, (NUMVERTS) I don't think you can do this? No, you're right, you can't. It silently substituted ld a, (NUMVERTS), so that loop was running quite a bit longer than it needed to and the result not being visibly different unless the polygon hits the first scanline. So easy to miss. To be honest, more than 50% of my bugs today have been the result of pyz80 silently substituting legal code for illegal code. All related to my sudden haziness on the z80, of course. On Sat, Oct 24, 2009 at 11:20 PM, Andrew Collier and...@intensity.org.uk wrote: On 24 Oct 2009, at 20:08, Thomas Harte wrote: Anyway, if some of you z80 experts could have a quick look and tell me if I'm making any obvious style errors or otherwise missing obvious optimisations — even if only on a peephole level — I'd be infinitely grateful. NUMVERTS: db 0 ... ld a, (NUMVERTS) I would write: NUMVERTS: equ $+1 ld a,00 i.e. the data byte of the instruction is overwritten when the symbol is used (other code can write the symbol as normal). You can safely do this even if you're writing to the next consecutive instruction (i.e. there are no pipelining issues to be concerned with. Naturally, I would be shot for proposing this on any processor newer than the Z80) This is a byte smaller, and 8 t-states faster (not much, but it can be useful if the value is used frequently. Of course, if you read the variable in several places only one of them can be modified in this way. Choose the one which is executed most often). You can do this for any instruction which takes a literal data byte or word (use EQU $+2 for an instruction which uses the index registers). The only gotcha is that you must be careful to write the correct data size back, i.e. never write a double-register to storage allocated by 'ld a,00' otherwise you will corrupt the following instruction. By the way: ld d, (NUMVERTS) I don't think you can do this? If you've managed to persuade pyz80 to accept that, I'd be interested to see what opcode it generated... NB. the transformed alternative *is* available. i.e.: NUMVERTS: equ $+1 ld d,00 HTH, Andrew -- http://www.intensity.org.uk/
Re: Getting back into z80 programming (code included)
d ; de = adjustDown ld b, 0 ld c, a ; bc = adjustUp 1 ld h, b ld l, c and a sbc hl, de ; hl = errorTerm sla c rlc b ; bc = adjustUp exx ld a, d srl a inc a ; a = initialPixelCount = finalPixelCount, d = wholeStep push af ; store for finalPixelCount ld a, d sra a ; test for wholeStep1 exx jr nc, @+nolowbit ; errorTerm += yDelta (double errorTerm, add adjustDown, halve it) add hl, hl add hl, de sra h rr l jr @+lowbitdone @nolowbit: ; if !adjustUp then initialPixelCount-- ld (@+astorepos+1), a ld a, b or c @astorepos: ld a, 23 jr nz, @+noadjust exx dec a jr @+lowbitdone @noadjust: @lowbitdone: dec de exx ; To here: ; ; e = initialixelCount ; b = x1, c = y1 ; d = wholeStep ; //e = yDelta ; hl' = errorTerm ; bc' = adjustUp ; de' = adjustDown + 1 ; hl = address of table ; top of stack = af pair with a = finalPixelCount pop af push af srl a xor 255 inc a add b ld (hl), a ; will progress with a = x inc l dec e jr z, @+noloop @storeloop: sub d exx adc hl, bc ; to ensure flags set; carry is clear from the add d jr nc, @+noextra; no carry = negative or zero? dec a sbc hl, de ; carry will be set, but predecremented de @noextra: exx ld (hl), a inc l dec e jr nz, @-storeloop @noloop: pop bc sub b ld (hl), a jr @+endOfPushToArray @vertical: ; positive xdelta is in a, compare to positive ydelta from e ld l, c ld c, b ld b, e @vloop: ld (hl), c inc l djnz @-vloop @endOfPushToArray: pop hl pop bc pop af pop de ret @SPBackup: dw 0 ; ; DIV88 - 8 bit divide with remainder; adapted from slightly broken version ; at http://map.grauw.nl/sources/external/z80bits.html ; ; input: d = dividend, e = divisor, a = 0 ; output: d = quotient, a = remainder ; ; clobbered: f ; ; takes between 243 and 351 cycles ; DIV88: sla d rla cp e jr c, @+C1 @NC0: sub e sl1 d rla cp e jr c, @+C2 @NC1: sub e sl1 d rla cp e jr c, @+C3 @NC2: sub e sl1 d rla cp e jr c, @+C4 @NC3: sub e sl1 d rla cp e jr c, @+C5 @NC4: sub e sl1 d rla cp e jr c, @+C6 @NC5: sub e sl1 d rla cp e jr c, @+C7 @NC6: sub e sl1 d rla cp e jr c, @+C8 @NC7: sub e sl1 d ret @C1: sla d rla cp e jr nc, @-NC1 @C2: sla d rla cp e jr nc, @-NC2 @C3: sla d rla cp e jr nc, @-NC3 @C4: sla d rla cp e jr nc, @-NC4 @C5: sla d rla cp e jr nc, @-NC5 @C6: sla d rla cp e jr nc, @-NC6 @C7: sla d rla cp e jr nc, @-NC7 @C8: sla d rla ret On Sat, Oct 24, 2009 at 11:46 PM, Thomas Harte tomh.retros...@gmail.com wrote: One trick I almost
Re: Getting back into z80 programming (code included)
Oh, your implied guess was quite right, I was a version behind. I'd say you fooled me by leaving Version 1.1, released 13 April 2007 at the top of the read me despite having updated the version history but actually I spotted 1.2, downloaded it and then failed to do anything more whatsoever. Entirely my own fault, apologies. On Sun, Oct 25, 2009 at 12:09 AM, Andrew Collier and...@intensity.org.uk wrote: On 24 Oct 2009, at 23:46, Thomas Harte wrote: By the way: ld d, (NUMVERTS) I don't think you can do this? No, you're right, you can't. It silently substituted ld a, (NUMVERTS), so that loop was running quite a bit longer than it needed to and the result not being visibly different unless the polygon hits the first scanline. So easy to miss. Which version of pyz80 are you using? For me, this instruction is caught by a testcase: $ cat test.z80s NUMVERTS: db 0 ld d,(NUMVERTS) $ pyz80 test.z80s pass 1 ... Error: Illegal combination of operands test.z80s:1 ld d,(NUMVERTS) Error: OpCode not recognised test.z80s:1 ld d,(NUMVERTS) Presumably your longer code sequence is catching it out somehow... As an aside, it's rather unfortunate that zilog chose to use parentheses to denote memory dereferences, as they're ambiguous with mathematical ordering operators. It's not immediately obvious that the following examples generate entirely different instructions, but that is a consequence of the only useful way I could parse them! ld hl,(NUMVERTS + 1) ld hl,(NUMVERTS) + 1 Andrew -- http://www.intensity.org.uk/
Re: Getting back into z80 programming (code included)
If you're looking for an excuse to make a new release, it seems still to accept illegal conditions on jr, like jr m, [symbol]. That specific one turns into ld e, b followed by a lone 0x01. On Sat, Oct 24, 2009 at 11:21 PM, Andrew Collier and...@intensity.org.uk wrote: On 25 Oct 2009, at 00:16, Thomas Harte wrote: you fooled me by leaving Version 1.1, released 13 April 2007 at the top of the read me Whoops! So it does. Fixed in svn (though I don't think I will do a re-release at this point...) Andrew -- http://www.intensity.org.uk/
Re: Getting back into z80 programming (code included)
Oh, also, I've discovered bugs in the code I published yesterday and a few cases where I've clearly switched mentally into 6502 mode (eg, xor 255/inc a instead of just using neg). I don't think there's any value in dumping my code ad nauseam, but should anyone consider actually using the stuff I previously presented, they should be wary. Tying this to my recent questions about interrupts: I'm mindful that if I use SP to draw scanlines with interrupts enabled, I will occasionally get 2 or 4 pixels of noise at the left edge of my scanlines if I leave interrupts enabled. However, I'm not aware of any way of tracking time other than hsync counting. Also, I'm triple buffering, so hsync catching allows me to advance a video page cleanly. Ideally I'd be able to disable interrupts to draw the scanline, then test at interrupt enable whether I'd missed one. But I guess there's no real way of achieving that? My understanding is that HPEN doesn't count outside the pixel area and the display interrupt will automatically expire in 20 us. I guess I can store HPEN before disabling interrupts, reset my stored value at interrupt, and if in execution generally I spot that it is lower than the stored value is greater than the hardware value then trigger a fake interrupt. But that's much less than neat. On Sun, Oct 25, 2009 at 9:21 PM, Thomas Harte tomh.retros...@gmail.com wrote: If you're looking for an excuse to make a new release, it seems still to accept illegal conditions on jr, like jr m, [symbol]. That specific one turns into ld e, b followed by a lone 0x01. On Sat, Oct 24, 2009 at 11:21 PM, Andrew Collier and...@intensity.org.uk wrote: On 25 Oct 2009, at 00:16, Thomas Harte wrote: you fooled me by leaving Version 1.1, released 13 April 2007 at the top of the read me Whoops! So it does. Fixed in svn (though I don't think I will do a re-release at this point...) Andrew -- http://www.intensity.org.uk/
The 3d demo I supplied for Sam Revival 22
It's a bit old and not representative of my most recent stuff but was always intended to be public domain so get your spinning Cobra Mk3 here: http://members.allegro.cc/ThomasHarte/temp/short-3d-demo.zip Attempts to upload to incoming on ftp://ftp.nvg.ntnu.no/pub/sam-coupe/ failed with a permissions error. As it's public domain, please anyone feel able to upload it there or anywhere else. The demo on Sam Revival 23 is much better.
Re: The 3d demo I supplied for Sam Revival 22
I didn't keep one, but will attempt to reproduce the problem tonight. Given my level of expertise, I'd say there's maybe a 10% probability that there's actually anything wrong on the NVG side... On Fri, Apr 16, 2010 at 5:52 AM, Frode Tennebø fr...@tennebo.com wrote: On Fri, 16 Apr 2010 00:17:06 +0200, Thomas Harte tomh.retros...@gmail.com wrote: Attempts to upload to incoming on ftp://ftp.nvg.ntnu.no/pub/sam-coupe/ failed with a permissions error. As it's public domain, please anyone feel able to upload it there or anywhere else. Could you please give me a log of the session as I'm not able to repeat any error? -Frode -- ^ Frode Tennebø | email: fr...@tennebo.com | fr...@irc ^ | with Standard.Disclaimer; use Standard.Disclaimer; |
Re: The 3d demo I supplied for Sam Revival 22
Actually, reduce that to 0.0001% probability since I've now succeeded. The file is duplicated in the incoming directory of NVG. On Fri, Apr 16, 2010 at 3:26 PM, Thomas Harte tomh.retros...@gmail.com wrote: I didn't keep one, but will attempt to reproduce the problem tonight. Given my level of expertise, I'd say there's maybe a 10% probability that there's actually anything wrong on the NVG side... On Fri, Apr 16, 2010 at 5:52 AM, Frode Tennebø fr...@tennebo.com wrote: On Fri, 16 Apr 2010 00:17:06 +0200, Thomas Harte tomh.retros...@gmail.com wrote: Attempts to upload to incoming on ftp://ftp.nvg.ntnu.no/pub/sam-coupe/ failed with a permissions error. As it's public domain, please anyone feel able to upload it there or anywhere else. Could you please give me a log of the session as I'm not able to repeat any error? -Frode -- ^ Frode Tennebø | email: fr...@tennebo.com | fr...@irc ^ | with Standard.Disclaimer; use Standard.Disclaimer; |
Re: Any high level language cross compilers?
Those aren't cross compilers; a cross compiler would convert a high level language such as C to a Sam Coupe binary on a platform like the PC. Sam C and Sam Vision run directly on the Sam, making them a lot harder to slot into a development environment and likely to operate more slowly and with lower quality output (since there's a speed/space/time trade-off involved in compiler construction, at least on smaller machines). Anyway, I'll look into z88dk having not even heard of it before. At the minute I'm reading the Smalltalk-80 book and it's very interesting, even as someone who does Objective-C every day. On Sat, Apr 24, 2010 at 11:50 AM, Roger Jowett rogerjow...@gmail.com wrote: sam c sam vision? On 23 April 2010 17:56, david brant davidcbr...@yahoo.com wrote: On 23 Apr 2010, at 13:38, Thomas Harte wrote: For the Sam, obviously. And being not down with the kids, I'm considering stuff like C to be a high level language. Failing that, are there any well supported cross compilers for the z80 in general? Otherwise I'm quite tempted to have a bash at one myself. Have been thinking of doing a C compiler using Jam Assembler's core but thats as far as its got.
Re: The 3d demo I supplied for Sam Revival 22
I really should find the time to finish off the documentation and get it out there. I still have the vague notion of attaching or creating a high level language for the game logic parts that aren't so time critical, but don't intend to treat the issue as a sticking point. I really, really need to finish off the documentation. For Roger, and generally: it's Mode 4 but a traditional Bresenham rasteriser makes anti-aliasing difficult to achieve without switching to a slower algorithm. Models are described as vertices (seven bytes each), faces (ten bytes each) and edges (thirteen bytes each). Then there's twelve bytes to complete the model by tying the faces, edges and vertices together and for each instance of the model another eighteen bytes of positioning and rotation stuff. It's all still Eulers at the minute, though it all turns into matrices lower down so that wouldn't be too hard to replace. There was a late-stage 'optimisation' to do with objects that are mirrored across the x axis, which saves space and processing time for those. In retrospect I'm not sure it was that good an idea as the time saving may not be justified by the complexity. Per the Sam's paging scheme things are all a bit complicated, but per the standard design, models go on the same page as the internal lib3d code. From memory, that makes 15 or 20kb space for models. The Cobra Mk3 occupies 698 bytes, the cube 246 bytes, the Adder 524 bytes. On Sat, Apr 24, 2010 at 10:56 AM, the_wub ! the...@gmail.com wrote: Hi Thomas, I've finally managed to test the Sam Revival 23 cover disk version, and it's very exciting! Great work! I'm really looking forward to having a go at making something with this, or at least trying to.. ;) Rob.
Re: Any high level language cross compilers?
Not a clue about websites; Objective-C is the usual language for Mac and [native] iPhone stuff — it's a lot of the object/messaging stuff of Smalltalk grafted onto the top of C. So it's either the flexibility and power of Smalltalk with the ability to drop into C for performance critical stuff or it's all the speed of Smalltalk with all the memory management safety of C, depending on how you prefer to look at it. On Sat, Apr 24, 2010 at 3:16 PM, Roger Jowett rogerjow...@gmail.com wrote: you do objective c? does that mean you know how to get a website to detect the screen resolution? maybe the font size too? On 24 April 2010 14:32, Thomas Harte tomh.retros...@gmail.com wrote: Those aren't cross compilers; a cross compiler would convert a high level language such as C to a Sam Coupe binary on a platform like the PC. Sam C and Sam Vision run directly on the Sam, making them a lot harder to slot into a development environment and likely to operate more slowly and with lower quality output (since there's a speed/space/time trade-off involved in compiler construction, at least on smaller machines). Anyway, I'll look into z88dk having not even heard of it before. At the minute I'm reading the Smalltalk-80 book and it's very interesting, even as someone who does Objective-C every day. On Sat, Apr 24, 2010 at 11:50 AM, Roger Jowett rogerjow...@gmail.com wrote: sam c sam vision? On 23 April 2010 17:56, david brant davidcbr...@yahoo.com wrote: On 23 Apr 2010, at 13:38, Thomas Harte wrote: For the Sam, obviously. And being not down with the kids, I'm considering stuff like C to be a high level language. Failing that, are there any well supported cross compilers for the z80 in general? Otherwise I'm quite tempted to have a bash at one myself. Have been thinking of doing a C compiler using Jam Assembler's core but thats as far as its got.
Re: Some SAM hardware for sale
Oh, I sort of wish you'd listed the technical manual separately. I know there's a PDF about on the internet but it has a few OCR-style typos so I'm a bit wary of it. And I can't find it now, making me think it may not be legitimate to circulate. On Sun, May 9, 2010 at 3:47 PM, David Watson david.watson...@gmail.com wrote: Hi, Here's the ebay link to my Sam Coupe, it was recently taken out of the loft and played with ( I mean tested ), although as I am moving house I can't afford the space to keep it. It is fully working and comes with the advanced technical manual and original accessories. Lets hope someone can give it a good home. http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItemitem=130390021016 Thanks, -- David Watson http://www.planetwatson.co.uk Code is for life, use python
Re: Some SAM hardware for sale
Having obtained a physical copy of the manual in the interim, it's a shame that none of the appendices are included. The datasheets are probably redundant, but Appendix C is Sam specific, with some useful bits like the key map. For the very first time I miss the automatic feed scanner that I had access to two works ago. I have to admit that re: the current online version, I may have been too quickly discouraged by the reference to 'HGT' on page 2, which made me think there might be a few vital 0s turned into 8s or vice versa. From a random check of three pages, I think you're right that most things that are amiss are obviously so in context such that the digital copy is a suitable substitute. Specifically, I checked: Page 52: an extra full stop has appeared after 'calculator memory 0-5 on' about halfway down the page, commonly has become 'comanonly' in the text below that. Page 73: system variable 'STRM16NM' is incorrectly named as 'STRMX6NN', 'PAGCOUNT' as 'PACCOUNT', 'BCREG' as 'ECREG', 'AUTOFLG' as 'AUTOFLO', 'MYCRD' as 'MYORD', lots of minor errors like 'hold' turned to 'bold', an 0 turned into an O, a word decapitalised, etc. Page 34: no errors. One I get access to a program that'll open the DOC file in the zip (I'm sure Microsoft Word would oblige) then I'll submit corrections. On Sun, May 9, 2010 at 10:39 PM, Frode Tennebø fr...@tennebo.com wrote: On Sun, 09 May 2010 23:04:53 +0200, Thomas Harte tomh.retros...@gmail.com wrote: Oh, I sort of wish you'd listed the technical manual separately. I know there's a PDF about on the internet but it has a few OCR-style typos so I'm a bit wary of it. And I can't find it now, making me think it may not be legitimate to circulate. You mean this one? ftp://ftp.nvg.ntnu.no/pub/sam-coupe/docs/manuals/software/SAM%20Coup%E9%20Technical%20Manual.zip There are probably typos, but I was not aware of anything major... -Frode -- ^ Frode Tennebø | email: fr...@tennebo.com | fr...@irc ^ | with Standard.Disclaimer; use Standard.Disclaimer; |
Re: Some SAM hardware for sale
Nope, shouldn't be. I've not done anything particularly clever anywhere. I think there's some minor dynamic reprogramming, but not beyond changing constants attached to immediate operations. That said, I can release the source tonight as I always intended to. The only problem is that the attached documentation doesn't quite document the internal formats for a model, etc. There's a full breakdown of the memory model employed and the supplied methods to call to do different things, along with the demo as on the most recent Sam Revival as an example program (though I'll chop that down a bit), you're just left dangling if you want to add any additional 3d models. I had some C code I was using to build the models (you call add vertex and add face methods, it dumps assembly code for you), I'll see if I can find that. I think it's definitely right to stop just sitting here, even if it means releasing less than I'd have liked. And for the record, yes I'd do a much better job if I were starting again from scratch. On Tue, May 25, 2010 at 4:02 PM, Roger Jowett rogerjow...@gmail.com wrote: is it difficult to disassmeble the 3d routines you made? On 22 May 2010 17:58, Thomas Harte tomh.retros...@gmail.com wrote: Having obtained a physical copy of the manual in the interim, it's a shame that none of the appendices are included. The datasheets are probably redundant, but Appendix C is Sam specific, with some useful bits like the key map. For the very first time I miss the automatic feed scanner that I had access to two works ago. I have to admit that re: the current online version, I may have been too quickly discouraged by the reference to 'HGT' on page 2, which made me think there might be a few vital 0s turned into 8s or vice versa. From a random check of three pages, I think you're right that most things that are amiss are obviously so in context such that the digital copy is a suitable substitute. Specifically, I checked: Page 52: an extra full stop has appeared after 'calculator memory 0-5 on' about halfway down the page, commonly has become 'comanonly' in the text below that. Page 73: system variable 'STRM16NM' is incorrectly named as 'STRMX6NN', 'PAGCOUNT' as 'PACCOUNT', 'BCREG' as 'ECREG', 'AUTOFLG' as 'AUTOFLO', 'MYCRD' as 'MYORD', lots of minor errors like 'hold' turned to 'bold', an 0 turned into an O, a word decapitalised, etc. Page 34: no errors. One I get access to a program that'll open the DOC file in the zip (I'm sure Microsoft Word would oblige) then I'll submit corrections. On Sun, May 9, 2010 at 10:39 PM, Frode Tennebø fr...@tennebo.com wrote: On Sun, 09 May 2010 23:04:53 +0200, Thomas Harte tomh.retros...@gmail.com wrote: Oh, I sort of wish you'd listed the technical manual separately. I know there's a PDF about on the internet but it has a few OCR-style typos so I'm a bit wary of it. And I can't find it now, making me think it may not be legitimate to circulate. You mean this one? ftp://ftp.nvg.ntnu.no/pub/sam-coupe/docs/manuals/software/SAM%20Coup%E9%20Technical%20Manual.zip There are probably typos, but I was not aware of anything major... -Frode -- ^ Frode Tennebø | email: fr...@tennebo.com | fr...@irc ^ | with Standard.Disclaimer; use Standard.Disclaimer; |
First public release of my 3d library
Get it here: http://members.allegro.cc/ThomasHarte/temp/Sam3d-01.zip If you have pyz80 then it should build out of the box to produce a spinning Cobra Mk3 demo a lot like the one on Sam Revival 22 (ie, the older of my demos) but faster and more accurate. And that the camera starts in an odd position (actually the same position relative to the Cobra as in the demo on Sam Revival 23, but without any of the other objects in the scene). Some documentation is included in a variety of formats, but the data formats are currently documented in the source only. Nevertheless, I'm optimistic it'll be reasonably straightforward and I'm happy to answer any questions. The 2008 modification dates on some of the files are embarrassingly accurate, and would probably be more prolific if I hadn't just performed a quick tidy up.
Re: Some SAM hardware for sale
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't a fixed point DDA method) would be faster in principle. I guess you'd ideally switch from one to the other depending on line length. If so, then obviously that would help in Mode 3 where lines are, on average, twice as long in pixels. In the code I've just released, change the line drawer in drawline.z80s and then the constants on lines 661, 663 and 145 to implement an alternative graphics mode. On Tue, May 25, 2010 at 4:34 PM, Roger Jowett rogerjow...@gmail.com wrote: impossible to use your routines to pluck 3d data for objects from other 48 softwrae loaded as a snapshot into ram? you couldnt use such a method to add a 3d part to the +d hacker/softcrack 9 multiface and +d sopftware they seemed to have sprite grabbers for 2d stuff only nohting for 3d - something like the starglider when docked the computer offers a selection of all the 3d stuff in the game for viewing? would be nice for others though the 48 would store coordinates for only mode 1 viewing? or does coordinate system not matter which mode the object is displayed in? do your routines work as fast in mode3? do you need to double the horizontal size in order to get around the rediculous fatpix cirlce fix? On 25 May 2010 16:29, Thomas Harte tomh.retros...@gmail.com wrote: Nope, shouldn't be. I've not done anything particularly clever anywhere. I think there's some minor dynamic reprogramming, but not beyond changing constants attached to immediate operations. That said, I can release the source tonight as I always intended to. The only problem is that the attached documentation doesn't quite document the internal formats for a model, etc. There's a full breakdown of the memory model employed and the supplied methods to call to do different things, along with the demo as on the most recent Sam Revival as an example program (though I'll chop that down a bit), you're just left dangling if you want to add any additional 3d models. I had some C code I was using to build the models (you call add vertex and add face methods, it dumps assembly code for you), I'll see if I can find that. I think it's definitely right to stop just sitting here, even if it means releasing less than I'd have liked. And for the record, yes I'd do a much better job if I were starting again from scratch. On Tue, May 25, 2010 at 4:02 PM, Roger Jowett rogerjow...@gmail.com wrote: is it difficult to disassmeble the 3d routines you made? On 22 May 2010 17:58, Thomas Harte tomh.retros...@gmail.com wrote: Having obtained a physical copy of the manual in the interim, it's a shame that none of the appendices are included. The datasheets are probably redundant, but Appendix C is Sam specific, with some useful bits like the key map. For the very first time I miss the automatic feed scanner that I had access to two works ago. I have to admit that re: the current online version, I may have been too quickly discouraged by the reference to 'HGT' on page 2, which made me think there might be a few vital 0s turned into 8s or vice versa. From a random check of three pages, I think you're right that most things that are amiss are obviously so in context such that the digital copy is a suitable substitute. Specifically, I checked: Page 52: an extra full stop has appeared after 'calculator memory 0-5 on' about halfway down the page, commonly has become 'comanonly' in the text below that. Page 73: system variable 'STRM16NM' is incorrectly named as 'STRMX6NN', 'PAGCOUNT' as 'PACCOUNT', 'BCREG' as 'ECREG', 'AUTOFLG' as 'AUTOFLO', 'MYCRD' as 'MYORD', lots of minor errors like 'hold' turned to 'bold', an 0 turned into an O, a word decapitalised, etc. Page 34: no errors. One I get access to a program that'll open the DOC file in the zip (I'm sure Microsoft Word would oblige) then I'll submit corrections. On Sun, May 9, 2010 at 10:39 PM, Frode Tennebø fr...@tennebo.com wrote: On Sun, 09 May 2010 23:04:53 +0200, Thomas Harte tomh.retros...@gmail.com wrote: Oh, I sort of wish you'd listed the technical manual separately. I know there's a PDF about on the internet but it has a few OCR-style typos so I'm a bit wary of it. And I can't find it now, making me think it may not be legitimate to circulate. You mean this one? ftp://ftp.nvg.ntnu.no
Re: First public release of my 3d library
Oh, gosh, sorry. The default installation option for OS X is a case insensitive filing system, hence my failure to spot this. I hope to pull the data structure information into the manual and update the release at some point, I'll fix the case then too. On Tue, May 25, 2010 at 9:35 PM, David Sanders dsuzukisand...@gmail.com wrote: Some documentation is included in a variety of formats, but the data formats are currently documented in the source only. Nevertheless, I'm optimistic it'll be reasonably straightforward and I'm happy to answer any questions. The 2008 modification dates on some of the files are embarrassingly accurate, and would probably be more prolific if I hadn't just performed a quick tidy up. Works great here Thomas! Only caveat being that I needed to #mv init.z80s Init.z80s David
Re: First public release of my 3d library
There's now http://members.allegro.cc/ThomasHarte/temp/Sam3d-01b.zip with fixed filename case; the difference between being able to build straight out of the box and not being able to build is enough motivation. I've had a quick dig out of the C code I was using to build the models and had forgotten that it's tied to a C prototype of the 3d code which relies on the obscure and aged Allegro 2d graphics library and is currently outputting both the style of models used by the engine and a semi pre-compiled style that I was experimenting with but which made everything more complicated and memory hungry without providing sufficient benefit. So I'll rip off the useful bits and post that at some later date. Hopefully soon. On Tue, May 25, 2010 at 10:04 PM, Thomas Harte tomh.retros...@gmail.com wrote: Oh, gosh, sorry. The default installation option for OS X is a case insensitive filing system, hence my failure to spot this. I hope to pull the data structure information into the manual and update the release at some point, I'll fix the case then too. On Tue, May 25, 2010 at 9:35 PM, David Sanders dsuzukisand...@gmail.com wrote: Some documentation is included in a variety of formats, but the data formats are currently documented in the source only. Nevertheless, I'm optimistic it'll be reasonably straightforward and I'm happy to answer any questions. The 2008 modification dates on some of the files are embarrassingly accurate, and would probably be more prolific if I hadn't just performed a quick tidy up. Works great here Thomas! Only caveat being that I needed to #mv init.z80s Init.z80s David
Re: Some SAM hardware for sale
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 rogerjow...@gmail.com wrote: does that mean that mode one reoutines might work in mode 2 then? On 25 May 2010 21:04, Thomas Harte tomh.retros...@gmail.com 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't a fixed point DDA method) would be faster in principle. I guess you'd ideally switch from one to the other depending on line length. If so, then obviously that would help in Mode 3 where lines are, on average, twice as long in pixels. In the code I've just released, change the line drawer in drawline.z80s and then the constants on lines 661, 663 and 145 to implement an alternative graphics mode. On Tue, May 25, 2010 at 4:34 PM, Roger Jowett rogerjow...@gmail.com wrote: impossible to use your routines to pluck 3d data for objects from other 48 softwrae loaded as a snapshot into ram? you couldnt use such a method to add a 3d part to the +d hacker/softcrack 9 multiface and +d sopftware they seemed to have sprite grabbers for 2d stuff only nohting for 3d - something like the starglider when docked the computer offers a selection of all the 3d stuff in the game for viewing? would be nice for others though the 48 would store coordinates for only mode 1 viewing? or does coordinate system not matter which mode the object is displayed in? do your routines work as fast in mode3? do you need to double the horizontal size in order to get around the rediculous fatpix cirlce fix? On 25 May 2010 16:29, Thomas Harte tomh.retros...@gmail.com wrote: Nope, shouldn't be. I've not done anything particularly clever anywhere. I think there's some minor dynamic reprogramming, but not beyond changing constants attached to immediate operations. That said, I can release the source tonight as I always intended to. The only problem is that the attached documentation doesn't quite document the internal formats for a model, etc. There's a full breakdown of the memory model employed and the supplied methods to call to do different things, along with the demo as on the most recent Sam Revival as an example program (though I'll chop that down a bit), you're just left dangling if you want to add any additional 3d models. I had some C code I was using to build the models (you call add vertex and add face methods, it dumps assembly code for you), I'll see if I can find that. I think it's definitely right to stop just sitting here, even if it means releasing less than I'd have liked. And for the record, yes I'd do a much better job if I were starting again from scratch. On Tue, May 25, 2010 at 4:02 PM, Roger Jowett rogerjow...@gmail.com wrote: is it difficult to disassmeble the 3d routines you made? On 22 May 2010 17:58, Thomas Harte tomh.retros...@gmail.com wrote: Having obtained a physical copy of the manual in the interim, it's a shame that none of the appendices are included. The datasheets are probably redundant, but Appendix C is Sam specific, with some useful bits like the key map. For the very first time I miss the automatic feed scanner that I had access to two works ago. I have to admit that re: the current online version, I may have been too quickly discouraged by the reference to 'HGT' on page 2, which made me think
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 rogerjow...@gmail.com 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 tomh.retros...@gmail.com 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 rogerjow...@gmail.com wrote: does that mean that mode one reoutines might work in mode 2 then? On 25 May 2010 21:04, Thomas Harte tomh.retros...@gmail.com 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't a fixed point DDA method) would be faster in principle. I guess you'd ideally switch from one to the other depending on line length. If so, then obviously that would help in Mode 3 where lines are, on average, twice as long in pixels. In the code I've just released, change the line drawer in drawline.z80s and then the constants on lines 661, 663 and 145 to implement an alternative graphics mode. On Tue, May 25, 2010 at 4:34 PM, Roger Jowett rogerjow...@gmail.com wrote: impossible to use your routines
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 rogerjow...@gmail.com wrote: how are lines drawn using rom routine or your own? On 27 May 2010 15:14, Thomas Harte tomh.retros...@gmail.com 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 rogerjow...@gmail.com 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 tomh.retros...@gmail.com 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 rogerjow...@gmail.com 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
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 tomh.retros...@gmail.com 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 tomh.retros...@gmail.com 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 rogerjow...@gmail.com wrote: how are lines drawn using rom routine or your own? On 27 May 2010 15:14, Thomas Harte tomh.retros...@gmail.com 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 rogerjow...@gmail.com 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 tomh.retros...@gmail.com 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
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 rogerjow...@gmail.com wrote: http://www.worldofspectrum.org/infoseek.cgi?regexp=^Freescape$phraseloadpics=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 rogerjow...@gmail.com 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$phraseloadpics=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 starglider12 carrier command elite ocean battle command realtime starstrike 12 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 tomh.retros...@gmail.com 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 tomh.retros...@gmail.com 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 tomh.retros...@gmail.com wrote: My own routine. It's
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 rogerjow...@gmail.com 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 tomh.retros...@gmail.com 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 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 rogerjow...@gmail.com wrote
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 ! the...@gmail.com 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 ! the...@gmail.com 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 ! the...@gmail.com 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 and...@intensity.org.uk wrote: On 20 July 2010 14:03, Simon Owen simon.o...@simcoupe.org 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 ! the...@gmail.com 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 ! the...@gmail.com 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 propose, as I barely
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 ! the...@gmail.com 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 ! the...@gmail.com 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 ! the...@gmail.com 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 stefan.dris...@gmail.com 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 tomh.retros...@gmail.com 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 stefan.dris...@gmail.com 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 tomh.retros...@gmail.com 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 stefan.dris...@gmail.com 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 stefan.dris...@gmail.com 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 tomh.retros...@gmail.com 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 stefan.dris...@gmail.com 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
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 tomh.retros...@gmail.com 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 stefan.dris...@gmail.com 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 tomh.retros...@gmail.com 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 stefan.dris...@gmail.com wrote: Fair enough. You could of course create PNG tiles so that you do not need to Flash! anything. You could
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 adr...@apbcomputerservices.co.uk 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 tomh.retros...@gmail.com 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 stefan.dris...@gmail.com 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 tomh.retros...@gmail.com 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
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 tomh.retros...@gmail.com 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 adr...@apbcomputerservices.co.uk 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 tomh.retros...@gmail.com 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 stefan.dris...@gmail.com 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 tomh.retros...@gmail.com 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
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 adr...@apbcomputerservices.co.uk 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 tomh.retros...@gmail.com 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 adr...@apbcomputerservices.co.uk 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 tomh.retros...@gmail.com 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 stefan.dris...@gmail.com 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 adr...@apbcomputerservices.co.uk 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 adr...@apbcomputerservices.co.uk 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 tomh.retros...@gmail.com 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 adr...@apbcomputerservices.co.uk 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
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 adr...@apbcomputerservices.co.uk 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 tomh.retros...@gmail.com 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 adr...@apbcomputerservices.co.uk 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 tomh.retros...@gmail.com 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 tomh.retros...@gmail.com 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 adr...@apbcomputerservices.co.uk 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 adr...@apbcomputerservices.co.uk 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 tomh.retros...@gmail.com 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 tomh.retros...@gmail.com 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 adr...@apbcomputerservices.co.uk 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ø fr...@tennebo.com wrote: On Sun, 01 Aug 2010 10:18:55 +0200, Andrew Park alp...@ntlworld.com 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 adr...@apbcomputerservices.co.uk 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ø fr...@tennebo.com wrote: On Sun, 01 Aug 2010 10:18:55 +0200, Andrew Park alp...@ntlworld.com 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 tomh.retros...@gmail.com 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 adr...@apbcomputerservices.co.uk 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ø fr...@tennebo.com wrote: On Sun, 01 Aug 2010 10:18:55 +0200, Andrew Park alp...@ntlworld.com 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
