SAM's 20th Birthday

New Jam Assembler

Anyone help

Fully detailed instruction timing breakdown?

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.

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?

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.

ANNOUNCE: SAMflate - gzip file decoder

Hello all,

I would like to announce immediate availability of a new program:

SAMflate

- an implementation of the inflate decompression algorithm from  
RFC1951, as used by gzip and other compatible utilities. In other  
words, it's like gunzip for the Sam.

Note that I have not implemented the compression side - instead you  
use the standard gzip utility on your Mac/PC/Unix computer to compress  
a file, and SAMflate running on the Sam will decode it for you.

You can download it here:

http://www.worldofsam.org/freelinking/SAMflate

Source code is also available[1], for anyone who wants to incorporate  
it into other programs:

http://sourceforge.net/projects/samflate/

[1] At least it will be, as soon as sourceforge admins get around to  
approving the project

(requires pyz80 for assembly, I took a few shortcuts when writing it...)

Please have a go, and do let me know if you find it useful or if you  
have any trouble with it!

I'd be especially interested if you have a file it can't decode (there  
may be bugs in the handling of Block Types 0 and 1 - the code isn't  
really tested because I couldn't persuade gzip to make that sort of  
file to try it with! Block Type 2 is the most efficient, and gzip  
seems to use it for all compression levels 1 to 9, so it's unlikely  
that anyone will see that problem...)

Cheers,
Andrew

--

-- 
  ---       Andrew Collier         ----
   ---- http://www.intensity.org.uk/ ---
                                       --

ANNOUNCE: pyz80 updated

Hello,

I've made a few bug-fixes to pyz80 (a Z80 cross-assembler for Mac/PC/ 
Unix) and the new version is available to download now from the usual  
place:

http://sourceforge.net/projects/pyz80/

Version 1.2, 2 February 2009

	•	Add PRINT directive
	•	Local symbols used in an included file will search the parent file  
to find a definition
	•	Chooses more appropriate names for files on the Sam disk image,  
based on the input source filename (reported by Thomas Harte)
	•	Fixed options --obj and -o were incorrectly conflicting (reported  
by Thomas Harte)
	•	Fixed symbol names containing strings 0b and 0x were misparsed  
(fixed by Simon Owen)
	•	Fixed a misparseing of incorrect instructions of the form LD H,(23)  
(reported by Thomas Harte)

Cheers,
Andrew

--

-- 
---       Andrew Collier         ----
  ---- http://www.intensity.org.uk/ ---
                                      --

Who remembers about the floating point calculator?

Hi,

AS you may know, if you CALL a machine code routine with some  
parameters, they are pushed onto the ROM's floating point calculator  
stack. I'm trying to use this, but having some difficulty getting the  
numbers back out again. Can anyone spot what's going wrong?

Consider a routine taking two parameters, which I'll designate FROM  
and TO; each are addresses in BASIC format (i.e. between 16384 and  
540671) - I want to separate these into a (page+1) and offset of each  
address, and collect the resulting 16-bit values using JGETINT.

If I call the following routine with CALL (address), 32768, 81920 then  
the values which are returned in HL from the calls to JGETINT are, in  
order:
0x0000		; fine, 81920 mod 16384 == 0
0x0005		; fine, 82910 div 16384 == 5
0x00c0		; wrong - expect 32768 mode 16384 == 0
0x0000		; wrong - expect 32768 mode 16384 == 2

Are there any entry conditions to 0x28 or JGETINT which I need to obey  
and have forgotten about? Have I got the FPC sequence wrong?

Thanks in advance for any useful observations,
Andrew

ENTRY:
     cp 2
     jp nz, parameter_error

     rst 0x28 ; call floating point calculator, stack = FR,TO

     db 0x25 ; DUP       ; FR,TO,TO
     db 0xe2 ; STK16K    ; FR,TO,TO,16K
     db 0x08 ; MOD       ; FR,TO,TO\16K
     db 0x06 ; SWOP      ; FR,TO\16K,TO
     db 0xe2 ; STK16K    ; FR,TO\16K,TO,16K
     db 0x09 ; IDIV      ; FR,TO\16K,TO/16K

     db 0x1c ; SWOP13    ; TO/16K,TO\16K,FR

     db 0x25 ; DUP       ; TO/16K,TO\16K,FR,FR
     db 0xe2 ; STK16K    ; TO/16K,TO\16K,FR,FR,16K
     db 0x08 ; MOD       ; TO/16K,TO\16K,FR,FR\16K
     db 0x06 ; SWOP      ; TO/16K,TO\16K,FR\16K,FR
     db 0xe2 ; STK16K    ; TO/16K,TO\16K,FR\16K,FR,16K
     db 0x09 ; IDIV      ; TO/16K,TO\16K,FR\16K,FR/16K

     db 0x06 ; SWOP      ; TO/16K,TO\16K,FR/16K,FR\16K

     db 0x33 ; EXIT

     call JGETINT
     ld (FROM_os),hl

     call JGETINT
     ld a,h
     or a
     jr nz, invalid_argument_error
     ld a,l
     dec a
     cp 32
     jr nc, invalid_argument_error
     ld (FROM_page),a

     call JGETINT
     ld (TO_os),hl

     call JGETINT
     ld a,h
     or a
     jr nz, invalid_argument_error
     ld a,l
     dec a
     cp 32
     jr nc, invalid_argument_error
     ld (TO_page),a

--

-- 
  ---       Andrew Collier         ----
   ---- http://www.intensity.org.uk/ ---
                                       --

RE: SAM Revival issue 22 out now!

WOOHOO - Nice going :D

-----Original Message-----
From: owner-sam-users@... [mailto:owner-sam-users@...]
On Behalf Of Colin Piggot
Sent: 12 January 2009 00:16
To: Adrian
Subject: Re: SAM Revival issue 22 out now!

I wrote...
> Looks like I'll have to get my hands dirty with some Z80 at the
> weekend...

And I have!

The patched ROM3 is ready. By removing the rainbow stripes and the
copyright
message I freed up 130 bytes and just managed to squeeze my new code in
the
ROM to first check that the Trinity Ethernet Interface is connected then
fetch in a 1K bootblock from the Trinity's 128K EEPROM and execute it.

I've just got a simple test routine stored in the EEPROM for the time
being
so I could check it was all working, but the next step is to write code
so
it can then fetch in the full DOS from the EEPROM too which should be a
relatively straightforward task to write. Of course though the 1K
bootblock
in the EEPROM could contain whatever you want so there's nothing
stopping
anyone else to write their own code to pop in the EEPROM to execute on
startup.

I'll be writing up all what I've done for the next SAM Revival magazine
and
including all the source code for the ROM patch, the finished bootblock
and
installer for getting it to load DOS on startup. There'll also be some
skeleton code for creating your own bootblock routine for it to execute
on
startup.

I've got some EPROM chips on the way so will have the new ROMs available
later this week.

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/

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.