> Well, I think (I may be wrong though, I am not very familiar to Macs),
> that such a particular thing gets easier when compared to a QL or another
> emulator. Namely, I got an impression that Mac programs are mostly (or
> 100%) system clean. So you don't need to emulate the hardware, just the
The same mostly applies to the QL actually. The only hardware anyone
accessed directly was the screen and that mainly for games.
The main problem was to replace the hardware accesses (interrupts, keyboard
etc) in the OS itself with something that worked on an ST.
Figuring out a way around the protected lower memory wasn't easy either.
QDOS has system call vectors down there that applications in user mode
might read, and I know MacOS has similiar problems. On >='030 processors that
can be fixed via the MMU, though (not yet done in QLem).
> problem is to interface the Mac application to the Atari operating system
> (mostly GEMDOS and GEM itself). Both things (OSes) look quite similar,
> don't know about eventual differences in internals. I heard Macs use traps
> to call the system (some weird way, though), so if, by a strange
> coincidence, these traps are not the same as used by Atari, things start
> even more nice.
We'd have to put MacOS in its own memory space anyway, so that shouldn't
be a problem.
> BTW. I've seen your QL emulator, but I can't get it to work. Perhaps
It won't run on '040s yet (so I haven't been able to run it myself for
quite a while). :-(
> because I am lacking QL knowledge, but it looks strange anyways (why the
A new version has been on the way for a long time now, but I never seem
to get around to finishing up the documentation.
> hell the screen is white on the left, and red on the right??).
Because Sinclair designed it that way. ;-)
The left window is where your program code will appear by default and the
right is the output window. The black window at the bottom is where you
write your code.
Naturally, you can change the windows if you like (and in an application
you would of course do that, or open new windows).
The built in SuperBASIC is actually very good. It has procedures and functions
with local variables, multi-line 'if', 'while'/'do' loops etc etc, and it's
easy to extend with new instructions (written in assembly) which can do
anything the standard ones can.
Several compilers are available, one of which was _the_ best compiler available
for the QL for several years. The BCPL/C/Pascal compilers produced worse code.
To see the directory of a standard TOS/DOS floppy, use:
DIR dsk1 (for a normal QL floppy, use flp1 instead)
To load a SuperBASIC program:
LOAD dsk1_program_name
Many compiled programs are run via (some use SuperBASIC booters instead):
EXEC_W dsk1_executable_name
A silly little example program that may work (it's been a while...):
(this is just to show off the language a bit)
4 device$ = "scr_256x256a128x0"
5 open #4,device$
6 paper #4,7
7 ink #4,2
8 cls #4
9 input #0,"What scale: "; scale
10 rem IIRC, a window is always 100 heigh by default
15 for n = 0 to 100 step 2
20 draw_some #4, n, scale
30 end for n
90 rem ---
95 rem Procedure and function definitions
97 rem ---
100 def proc draw_some(ch, n, multiplier)
105 local x, y, center
110 x = n * multiplier
120 y = (1 - n) * multiplier
125 center = 50 * multiplier
130 line #ch,0,c2 to c1,0
135 circle center, center, n / 2
140 end proc
If you type this in, it will appear in the window to the left.
Type 'RUN' to start it.
--
Chalmers University | Why are these | e-mail: rand_at_cd.chalmers.se
of Technology | .signatures | johan_at_rand.thn.htu.se
| so hard to do | WWW/ftp: rand.thn.htu.se
Gothenburg, Sweden | well? | (MGIFv5, QLem, BAD MOOD)
Received on on. april 29 1998 - 17:15:00 CEST