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.
{Spam?} Re: New projects Byte-Back 2009
- Original Message - From: Thomas Harte [EMAIL PROTECTED] To: sam-users@nvg.ntnu.no Sent: Tuesday, October 07, 2008 7:25 PM Subject: Re: New projects Byte-Back 2009 TH Obviously this leaves a whole bunch of massive holes in what I can TH show; is anybody able to loan copies of Prince of Persia, Lemmings, TH Defender and anything else particularly worth showing? I no longer have an original Defender disk - however, you can grab the latest version from World Of Sam. Direct link below: http://www.worldofsam.org/files/active/0/DefenderArcadeConversionUpdated.zip Doesn't require anything special - just bung it on a floppy! Please use the Updated version (as linked to above) - as this is closer to the coin-op than previous versions. Chris...
Re: New projects Byte-Back 2009
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!
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!
Re: New projects Byte-Back 2009
Quoting Thomas Harte [EMAIL PROTECTED]: 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. Although they are good ones :)
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
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: 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/ --- --
