RE: Help with : Writing my first (decent) SAM program . . .
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David L Sent: 11 January 1998 01:27 I think your system date is slightly wrong there David. :) To: sam-users@nvg.ntnu.no Subject: Re: Help with : Writing my first (decent) SAM program . . . David L (erm, the other one). (That's Laundon in case anyone's forgotten.)
RE: Help with : Writing my first (decent) SAM program . . .
Ifyou've got a PC - the easiest solution is to get a PC TV card and use the REAL machine via the PC monitor... assuming you've got a PC that is ;) Have you tested this solution? In my experience (two cards - one Mac, one PC) the picture gets so mangled that text becomes impossible to read, for example. I don't think these things generally cope very well with unstandard signals. Oh great, the plan was to buy a PC (from Dave - bugger, I thought I'd never fall down to advertising) with the TV card and replace my TV completely - (shame I can't get rid of the TV License aswell) I'm hoping the newer TV cards can cope with SAM's screen... Justin.
Re: Help with : Writing my first (decent) SAM program . . .
-Original Message- From: Andrew Collier [EMAIL PROTECTED] To: sam-users@nvg.ntnu.no sam-users@nvg.ntnu.no Date: 15 May 1999 10:32 Subject: Re: Help with : Writing my first (decent) SAM program . . . November 1998? Get it sorted David /me shrugs Hey ho - I'll get round to it one of these days... David Ledbury, the walking advert. And y not?
RE: Help with : Writing my first (decent) SAM program . . .
David L wrote: If you've got a PC - the easiest solution is to get a PC TV card and use the REAL machine via the PC monitor... assuming you've got a PC that is ;) Is your picture clear enough? I borrowed a Haupage TV card but couldn't get a decent picture, as tho the signal wasn't strong enough. It was when I was fiddling with the controls in my PSU that I broke something, which is why my normal TV picture is streaky and blurred now! The normal TV picture was great on it... btw Dave, any idea what's happened to my Persona order? It's been about a month and I've still not heard a thing! Si
Re: Help with : Writing my first (decent) SAM program . . .
Of course, a bad situation got worse when the new EMC regulations came into force... Err. i am missing a point here, but what are those EMC regulations? Electro-Magnetic Compliance. Basically you're not allowed to sell any electic items unless they have taken, and passed, a very expensive testing procedure. Andrew -- | Andrew Collier | email [EMAIL PROTECTED] | Talk sense to a | Part 2 NatSci | http://carou.sel.cam.ac.uk/ | fool and he ++ICQ:38645805-+ calls you foolish | Selwyn College Student Computer Support Team | -- Euripides
Re: Help with : Writing my first (decent) SAM program . . .
Van: Andrew Collier [EMAIL PROTECTED] Aan: sam-users@nvg.ntnu.no Onderwerp: Re: Help with : Writing my first (decent) SAM program . . . Datum: vrijdag, mei 14, 1999 10:53 Err. i am missing a point here, but what are those EMC regulations? Electro-Magnetic Compliance. Basically you're not allowed to sell any electic items unless they have taken, and passed, a very expensive testing procedure. Aha, another stupid ruling to frustate small companies, clearing the way for big ones who can afford such testing. Thanks -- Robert van der Veeke, aka RJV Graphics [EMAIL PROTECTED] Currently listening to : The Phantom Menace OST
Re: Help with : Writing my first (decent) SAM program . . .
At 2:26 am +0100 11/1/98, David L wrote: November 1998? Get it sorted David Ifyou've got a PC - the easiest solution is to get a PC TV card and use the REAL machine via the PC monitor... assuming you've got a PC that is ;) Have you tested this solution? In my experience (two cards - one Mac, one PC) the picture gets so mangled that text becomes impossible to read, for example. I don't think these things generally cope very well with unstandard signals. (Oh - and if u want one - mail me at work for more details ;) David Ledbury, the walking advert. Andrew -- | Andrew Collier | email [EMAIL PROTECTED] | Talk sense to a | Part 2 NatSci | http://carou.sel.cam.ac.uk/ | fool and he ++ICQ:38645805-+ calls you foolish | Selwyn College Student Computer Support Team | -- Euripides
Re: Help with : Writing my first (decent) SAM program . . .
Hi, Hello, I received SC-ASM the other day, and being not ill acquainted with z80 assembler and the workings of the ZX Spectrum, I've programmed a few basic things. You know, like pressing different keys activating different border colours and little things like that. I therefore notice that port 0xfe still does a lot of the same old Spectrum stuff. Yes, 254 (dec) is still the BORDER output port, but with a few differences; most importantly that you can set the border colour to be between 8 and 15 by setting bit 5, and that you can turn off the screen (in modes 3 and 4) by setting bit 7. More about that later. Now I want to do something better! Like a sprite moving around or something. Cool. Demos are always a good place to start :) So, I am wondering - what port by what method would I page memory in and out? Right, this is going to sound a bit complicated. you'll get used to it sooner or later :) The Sam's 512K RAM is arranged in 32 pages of 16K each. The ROM comes in two 16K sections, which go in sections A and D. As far as BASIC is concerned, 16384 is the start of RAM page 0. You can page any two consecutive pages into Z80 addresses 0 - 32767 (Low Memory, sections A and B), and any two consecutive pages into Z80 addresses 32768 - 65535 (High Memory, sections C and D). To page RAM into high memory, just output the first page number to bits 0-4 of HMPR = 251 dec (keep bits 5 - 7 zero, they control external memory and an obscure CLUT feature in Mode 3). To page RAM into low memory, output the first page number to bits 0-4 of LMPR = 250 dec. Bit 5 should be HIGH if the RAM page is to replace the ROM0 page in section A. Bit 6 should be LOW if the RAM page is to replace the ROM1 page in section D. (keep bit 7 zero, it controls write-protect in page A) So, for example: OUT 250,33 OUT 251,30 results in: SECTION A: 0 - 16383 : PAGE 1 SECTION B: 16384 - 32767 : PAGE 2 SECTION C: 32768 - 49151 : PAGE 30 SECTION D: 49152 - 65535 : PAGE 31 And where does the screen memory start? Where do you want it to? There is another port, VMPR = 252, which controls the screen location and mode. A mode 1 or 2 screen can be located at ANY page; a mode 3 or 4 screen can be located at any EVEN page. Bits 0-4 are the start page of the screen bitmap. Bits 5 and 6 control the mode (ie. subtract 1 from BASIC's mode number, and shift left a few times). Keep bit 7 zero, it controls MIDI out. Normally, the screen starts at page 30. If I page out the ROM can I use the lower 32k for the screen and the higher 32k for program . . . Yes indeed, though I normally do it the other way round to catch mode 1 interrupts. Note that when you call a machine code routine, it will normally initially be paged into section C (but not if the routine is in page 0 or 2!). So my code normally goes something like this: DUMP 1,0 ORG 32768 in a,(lmpr) ld (lmprs),a in a,(hmpr) ld (hmprs),a and 31 ;make sure ROM1 is paged out and we're not changing anything else or 32;make sure ROM0 is paged out out (lmpr),a ;the same memory is paged into sections C and A jp lmem ;jump to the copy in section A hmem: lmprs: equ $+1 ld a,00 ; restore the previous value as BASIC expects out (lmpr),a ret ; end ORG $-32768 defs 56-$ interrupt: ei ret lmem: in a,(vmpr) ld (vmprs),a and 31 ; don't fiddle with the MIDI bit or 96; a mode 4 screen out (hmpr),a ... ; do some interesting things vmprs: equ $+1 ld a,00 ; restore BASIC's value in case we changed it out (vmpr),a hmprs: equ $+32768 ld a,00 ; put the program back into section C out (hmpr),a jp hmem ; jump there and amongst other things neatly dodge the contended memory issues? Or is contended memory a whole different prospect on the SAM? Contended memory is quite a complex issue on the Sam. Basically, ALL instruction times are rounded up to the nearest 4 t-states, (and execution speed is approximately halved during the screen area. To get some of the speed back you can turn the screen off - as I mentioned earlier - but if you need the display on then basically you're stuck with the contention). See Based On An Idea issue 2 for a more detailed explanation... Also, I picked up on here that the SAM's video memory is sensibly arranged. Can I take it that it therefore that it is a true linear frame buffer in the same sense as a VBE2 (or even good old mode 13h) one is? I take it one pixel is four bytes? There are four video modes; MODE 1 is exactly the same as the Spectrum. Mode 2 is similar, but the bitmap is laid out left to right - top to bottom. The attribute map starts at an offset of 8192 bytes, and is also composed of 8pixel wide, single pixel high units, in the same order. Mode 3 is 512 pixels * 192 lines, where each pixel is 2 bits, laid out left to right - top to bottom. Mode 4 is 256 pixels * 192 lines. each pixel is 4 bits, laid out left to right - top to bottom. Note that the sixteen
Re: Help with : Writing my first (decent) SAM program . . .
On Fri, 14 May 1999, Andrew Collier wrote: lmem: in a,(vmpr) ld (vmprs),a and 31 ; don't fiddle with the MIDI bit or 96; a mode 4 screen out (hmpr),a Sorry about that, it was late at night and I must have been tired Obviously I meant: and 31 out (hmpr),a or 96 out (vmpr),a Andrew
RE: Help with : Writing my first (decent) SAM program . . .
and 31 ; don't fiddle with the MIDI bit Yeah.. You leave those MIDI bits alone! They haven't hurt anyone! :) J.
Re: Help with : Writing my first (decent) SAM program . . .
At 9:27 pm +0100 13/5/99, Stuart Brady wrote: What was the Kaleidoscope's display like? The Kaleidoscope was a bit pointless really. It incresed the Sam's palette range from 7-bit to 15-bit, but didn't increase the number of CLUT entries. ie. only sixteen colours on the screen at a time (modulo the coding techniques such as palette line, which only help in specific limited cases). Oh, and did anyone get round to selling a SAM Accelerator? No. Simon Cooke and Martin Rookyard has a working design, but unfortunately (due to a complete and total lack of support from the market-leading magazine editor, software publisher and hardware manufacturer at the time[1]) the accelerator never reached the market. Damn shame. More recently, the idea resurfaced for a while, in a project codenamed SamSon, which involved collecting together every upgrade that anyone had designed in the past five years, lumping it together into one new box, and giving Bob Brenchley all the credit for the finished product. Unfortunately he involved himself in the technical discussions as well as the management, so it all went a bit pear-shaped. Apparently what the Sam really needed was a brand-new 32K external ROM, but even that hasn't managed to get itself built yet. Of course, a bad situation got worse when the new EMC regulations came into force... Andrew [1] First it was called impossible - the idea couldn't ever get off the drawing board. Then Simon took a working prototype to a Gloucester show... so the accelerator was branded unnecessary, Sam users would never want or need it - the software runs fast enough as it is. -- | Andrew Collier | email [EMAIL PROTECTED] | Talk sense to a | Part 2 NatSci | http://carou.sel.cam.ac.uk/ | fool and he ++ICQ:38645805-+ calls you foolish | Selwyn College Student Computer Support Team | -- Euripides
Re: Help with : Writing my first (decent) SAM program . . .
If I page out the ROM can I use the lower 32k for the screen and the higher 32k for program . . . Yes. Andrew's already mentioned IM-1 interrupts, but you'll also need to stick your screen (assuming a mode-4 screen) in the top 32k if you want to retain use of the NMI button. If you're not worried about NMI and are planning on using IM-2 (or running DI) then it's faster to calculate screen pixel addresses for a mode-4 screen based at address zero. Chris.
Re: Help with : Writing my first (decent) SAM program . . .
Erm... No. You probably meant to say four /bits/ (a nibble). Four bytes is 32 bits per pixel? Not likely, on a SAM. The Kaleidoscope wasn't too bad, IIRC... But no programs supported it. Yeah, four bits, absolutely! It was late. And as for the Kaleidoscope, didn't the Newsdisk carry a demo? Besides, as far as I recall the SAM couldn't even scroll a page of regular graphics, what would a single handed z80 have been able to do with the 16bit colour (or whatever it was) of the Kaleidoscope? Andrew Collier wrote: The Sam's 512K RAM is arranged in 32 pages of 16K each. The ROM comes in two 16K sections, which go in sections A and D. As far as BASIC is concerned, 16384 is the start of RAM page 0. Actually I only have a 256k SAM (it is a genuine MGT one if that counts for anthing though), is it correct to assume that pages 1415 start in sections CD? Also, slightly less related, what are the pros and cons of developing in SIM Coupe? I have no method to connect my SAM to a monitor - so what is the compatibility like as far as simple uses such as mine will be? If I page out the ROM can I use the lower 32k for the screen and the higher 32k for program . . . Yes indeed, though I normally do it the other way round to catch mode 1 interrupts. 'mode 1 interrupts' - is there no 50Hz interrupt in other graphics modes? And, on a slight aside, is it actually 50Hz now, or still about 50.8? -Thomas
Re: Help with : Writing my first (decent) SAM program . . .
Erm... No. You probably meant to say four /bits/ (a nibble). Four bytes is 32 bits per pixel? Not likely, on a SAM. The Kaleidoscope wasn't too bad, IIRC... But no programs supported it. Yeah, four bits, absolutely! It was late. And as for the Kaleidoscope, didn't the Newsdisk carry a demo? Besides, as far as I recall the SAM couldn't even scroll a page of regular graphics, what would a single handed z80 have been able to do with the 16bit colour (or whatever it was) of the Kaleidoscope? The Kaleidoscope didn't increase the number of CLUT entries, or the resolution. There was still four bits per pixel, so there's no extra bitmap data to shift round. Andrew Collier wrote: The Sam's 512K RAM is arranged in 32 pages of 16K each. The ROM comes in two 16K sections, which go in sections A and D. As far as BASIC is concerned, 16384 is the start of RAM page 0. Actually I only have a 256k SAM (it is a genuine MGT one if that counts for anthing though), is it correct to assume that pages 1415 start in sections CD? That depends what you're trying to achieve The ROM normally outputs 31 to LMPR, which means that section A contains ROM0, and section B contains RAM page 0 which is where the system variables and stack are held. It will move HMPR around as appropriate, to access BASIC programs, the screen or machine code routines etc. If you CALL a machine code routine from BASIC, it will normally be paged into section C (except when the routine is located in pages 0 or 2, which get called in sections B and D.) The ROM keeps the default screen in pages 14 and 15 on a 256K Sam. The DOS would load into page 13. Also, slightly less related, what are the pros and cons of developing in SIM Coupe? I have no method to connect my SAM to a monitor - so what is the compatibility like as far as simple uses such as mine will be? Unless you start fiddling about with complex, demanding and exact timing issues, you're unlikely to have a problem. If I page out the ROM can I use the lower 32k for the screen and the higher 32k for program . . . Yes indeed, though I normally do it the other way round to catch mode 1 interrupts. 'mode 1 interrupts' - is there no 50Hz interrupt in other graphics modes? Mode 1 interrupts - I'm referring to processor interrupt mode 1, where the effect of an interrupt is to call 56 dec. This is as opposed to processor Interrupt Mode 2, which you may have already used on the Spectrum, which involves setting the I register to the high byte of a table of addresses etc etc. I don't use IM2 very often. Rest assured, the 50Hz frame interrupt occurs properly in all graphics modes. And, on a slight aside, is it actually 50Hz now, or still about 50.8? Actually, it's 50.0801282051... or something like that. Normally there are 625 scan lines in exactly 1/25 of a second. The SAM only displays 312 scan lines per frame, so (assuming that one scan line takes the same length of time in each case) then it should take 0.019968 seconds to display one frame. Andrew -- | Andrew Collier | email [EMAIL PROTECTED] | Talk sense to a | Part 2 NatSci | http://carou.sel.cam.ac.uk/ | fool and he ++ICQ:38645805-+ calls you foolish | Selwyn College Student Computer Support Team | -- Euripides
Re: Help with : Writing my first (decent) SAM program . . .
Van: Andrew Collier [EMAIL PROTECTED] Aan: sam-users@nvg.ntnu.no Onderwerp: Re: Help with : Writing my first (decent) SAM program . . . Datum: vrijdag, mei 14, 1999 6:42 Of course, a bad situation got worse when the new EMC regulations came into force... Err. i am missing a point here, but what are those EMC regulations? -- Robert van der Veeke, aka RJV Graphics [EMAIL PROTECTED] Currently listening to : The Phantom Menace OST
Re: Help with : Writing my first (decent) SAM program . . .
On Thu, 13 May 1999, Thomas Harte wrote: I take it one pixel is four bytes? Erm... No. You probably meant to say four /bits/ (a nibble). Four bytes is 32 bits per pixel? Not likely, on a SAM. The Kaleidoscope wasn't too bad, IIRC... But no programs supported it. What was the Kaleidoscope's display like? Oh, and did anyone get round to selling a SAM Accelerator? -- Stuart Brady
