learning asm.
Glen Herrmannsfeldt
"Kyle Root" <kapp...@myrealbox.com> wrote in message
news:I3L7b.6953$6Q3....@fe01.atl2.webusenet.com...
> I have very little programming language exposure (I took a year of
> basic in high school, and tried to learn java) and I'm really
> interested in assembler and was wondering what would be a good resource
> for a newb like me, and which assembler would you recommend?
Before learning assembler you should be reasonably proficient in a higher
level compiled language.
Java, C, C++, Fortran, or Pascal would be reasonable choices. You should
be able to write programs of at least 100 lines in one of those languages,
and debug it without help from someone else.
I would recommend the assembler language for whichever machine you have
access to, though I don't really find the Intel/Microsoft assembly a very
good first choice.
There are assemblers, such as JASMIN, to generate the intermediate JVM code
that Java compilers usually generate. I don't know that anyone has used
that as a first assembly language, but it is probably a better choice than
many others. If you do learn Java it might be a good choice.
-- glen
Roedy Green
<g...@ugcs.caltech.edu> wrote or quoted :
>> I have very little programming language exposure (I took a year of
>> basic in high school, and tried to learn java) and I'm really
>> interested in assembler and was wondering what would be a good resource
>> for a newb like me, and which assembler would you recommend?
To learn assembler, you want to start with very simple computer. The
Pentium does not fit that description.
If you could find some old Motorola 68000 Mac system. It would be
ideal. It has about the simplest assembler going.
An old Apple ][ with a 6502 would be another reasonable choice.
I have posted dozens of small DOS assembler programs on my website.
see http://mindprod.com/products.html and
http://mindprod.com/products2.html They come with source and are
heavily commented. Many people have written telling me they learned
assembler just from playing with these examples and modifying them.
They run just fine in DOS emulation on Win2K etc.
You can learn a fair bit by using a trace program like Periscope, and
just watching the code execute, instruction by instruction. You see
the effects on the registers and condition codes.
If you start tracing high level languages you realise how little time
is spend on calculation. It is nearly all housekeeping, building stack
frames, destroying them, calling a routine that calls a routine that
calls a routine that FINALLY sets a flag.
Another approach is to disassemble Java class files in to JASM, so you
can see the byte codes. the JVM is the instruction set of some real
computers, but it must be emulated in various ways on the Pentium.
See http://mindprod.com/jgloss/jasm.html
If you learn how JASM works, you will be a great shape to tackle the
much quirkier real life instruction sets.
--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
Glen Herrmannsfeldt
"Roedy Green" <ro...@mindprod.com> wrote in message
news:ece4mvkcmsb513i7p...@4ax.com...
> On Fri, 12 Sep 2003 20:29:23 GMT, "Glen Herrmannsfeldt"
> <g...@ugcs.caltech.edu> wrote or quoted :
>
> >> I have very little programming language exposure (I took a year of
> >> basic in high school, and tried to learn java) and I'm really
> >> interested in assembler and was wondering what would be a good resource
> >> for a newb like me, and which assembler would you recommend?
>
> To learn assembler, you want to start with very simple computer. The
> Pentium does not fit that description.
>
> If you could find some old Motorola 68000 Mac system. It would be
> ideal. It has about the simplest assembler going.
The x86 architecture is a little strange, but at the assembly level the
pentium isn't much worse than the 8086. To me, it isn't the machine that
makes it hard to learn, but the assembler itself. Many rules are there for
strange reasons, especially related to relocation.
Well, the first assembler that learned was S/370, which has a few strange
complications, but otherwise is pretty easy to understand.
I suppose the 68000 isn't bad, not much different in some ways than the
PDP-11 which I would also suggest as pretty easy to learn. While PDP-11
hardware is hard to find these days, emulators seem to be pretty easy to
find.
-- glen
(snip)
> Another approach is to disassemble Java class files in to JASM, so you
> can see the byte codes. the JVM is the instruction set of some real
> computers, but it must be emulated in various ways on the Pentium.
>
> See http://mindprod.com/jgloss/jasm.html
>
> If you learn how JASM works, you will be a great shape to tackle the
> much quirkier real life instruction sets.
If he considers Java as his primary high level language, that would probably
Chris Uppal
> "Kyle Root" <kapp...@myrealbox.com> wrote in message
> news:I3L7b.6953$6Q3....@fe01.atl2.webusenet.com...
> > I have very little programming language exposure (I took a year of
> > basic in high school, and tried to learn java) and I'm really
> > interested in assembler and was wondering what would be a good
> > resource for a newb like me, and which assembler would you
> > recommend?
>
> Before learning assembler you should be reasonably proficient in a
> higher level compiled language.
>
> Java, C, C++, Fortran, or Pascal would be reasonable choices. You
> should be able to write programs of at least 100 lines in one of
> those languages, and debug it without help from someone else.
>
> I would recommend the assembler language for whichever machine you
> have access to, though I don't really find the Intel/Microsoft
> assembly a very good first choice.
I didn't see the original post, so I'm replying to Kyle here.
I think the advice I've quoted is good.
If you *do* decide you want to learn to program the x86 range, then one problem
is that there are very few books that don't assume that you are wanting to
program MS-DOS. If that's what you want to do then fine, if not then two less
ancient books are:
Linux Assembly Language Programming
Bob Neveln
Assembly Language for Intel-based Computers
Kip R. Irvine
The first book is relatively easy reading, but is not intended to be at all
exhaustive (e.g. it doesn't cover floating point arithmetic at all). OTOH it
does talk a good bit about how to write Linux device drivers. I think it's
still a good and relevant read as a starter, even if you aren't intending to
program Linux. It's worth quoting the very last sentences:
"The surface has barely been scratched. But the way forward is open."
The second books is bigger, more thorough, and mostly assumes you are working
in a modern Windows environment (though it does have some stuff on MS-DOS).
I found both books helpful. But then, I haven't actually *done* any assembly
programming for real yet, so I don't know how many holes there are in my
knowledge that I have yet to fall into...
Incidentally, the Intel manuals for the x86 (available at www.intel.com --
somewhere) are quite a bit more readable than you'd expect (more than I'd
expected anyway). You can download the PDF versions for free; you do have to
register. A warning: I found I had to use IE as my browser or the
registration/login process didn't work ;-(
If you decide you'd rather learn Java and then learn how to do the Java
equivalent of assembly programming (if only as a step towards learning to
program real machines at that level) then the very recent thread "A better
language than Oolong", in comp.lang.java.machine may give you some hints.
-- chris
Roedy Green
<g...@ugcs.caltech.edu> wrote or quoted :
>
>The x86 architecture is a little strange, but at the assembly level the
>pentium isn't much worse than the 8086. To me, it isn't the machine that
>makes it hard to learn, but the assembler itself. Many rules are there for
>strange reasons, especially related to relocation.
Flat 32-bit mode is not as strange as 16-bit mode, but dealing with
segment registers is going to throw a newbie. Obviously too the
operating system interface is much more complicated in 32-bit mode.
The other problem with the Pentium is the way registers have magic
properties. You can only divide with DX:AX, you have to use SI to
chase a string and DI to change it. You must use CX to count loops.
I think learning byte code would be great training wheels.
It burns the "hair" off assembler.
Stephen Kellett
<g...@ugcs.caltech.edu> writes
>Before learning assembler you should be reasonably proficient in a higher
>level compiled language.
? 6502 was the first thing I learnt (well after VIC-20 Basic, which I
forgot as soon as I learnt 6502).
Stephen
--
Stephen Kellett
Object Media Limited http://www.objmedia.demon.co.uk
RSI Information: http://www.objmedia.demon.co.uk/rsi.html
Stephen Kellett
<ro...@mindprod.com> writes
>If you could find some old Motorola 68000 Mac system. It would be
>ideal. It has about the simplest assembler going.
And a great instruction set. Knocks spots of the x86. Shame the 68K
didn't make it further than the Mac/Amiga/AtariST.
Randall R Schulz
If you like the M68000, then you'll love the processor that inspired
it, the PDP-11.
Randall Schulz
Stephen Kellett
<rrsc...@cris.com> writes
>Stephen,
>
>If you like the M68000, then you'll love the processor that inspired
>it, the PDP-11.
Oh yeah, looked at that when I was doing my degree. Long time ago now.
Never worked on PDP-11 assembler, but I noticed the similarity. The 68K
instruction set was a real joy to use, unlike the x86 instruction set,
which as some other posters have noticed has a multitude of quirks...
"No Mr Kellett you can't count loops using that register, thats for
Source Indexes". Yeah, whatever :-)
And to think the first IBM PC was based on a 68K and Motorola couldn't
supply enough chipsets to get the contract for a full delivery . How
history would've been different.
The story is something like that, I'm sure someone will correct any
slipup I've made.
Jim Hansson
java Secrets by Elliotte Rusty Harold (IDG Books)
spends some chapters on how to write a java disassembler, by reading it and
by writing the code I gained a lot of knowleage of "java assembly"
Randall R Schulz
Stephen Kellett wrote:
> In message <%kK8b.21279$dk4.6...@typhoon.sonic.net>, Randall R
> Schulz <rrsc...@cris.com> writes
>
>> Stephen,
>>
>> If you like the M68000, then you'll love the processor that
>> inspired it, the PDP-11.
>
>
> Oh yeah, looked at that when I was doing my degree. Long time ago
> now. Never worked on PDP-11 assembler, but I noticed the
> similarity. The 68K instruction set was a real joy to use, unlike
> the x86 instruction set, which as some other posters have noticed
> has a multitude of quirks...
>
> "No Mr Kellett you can't count loops using that register, thats for
> Source Indexes". Yeah, whatever :-)
>
> And to think the first IBM PC was based on a 68K and Motorola
> couldn't supply enough chipsets to get the contract for a full
> delivery . How history would've been different.
>
> The story is something like that, I'm sure someone will correct any
> slipup I've made.
>
> Stephen
Stephen,
I did learn PDP-11 assembly and wrote programs in it for one of my
undergraduate courses (among other things, this was the course in
which the concept of recursive subroutines were introduced in the CS
curriculum of that institution in that era). The instruction set is so
elegant and the opcode formats so regular and predictable, that for
years I could use the front panel switches (!) to key in an interrupt
driven routine to echo keyboard input back to the TTY / CRT.
Randall SChulz
Stephen Kellett
<rrsc...@cris.com> writes
>I did learn PDP-11 assembly and wrote programs in it for one of my
>undergraduate courses (among other things, this was the course in
>which the concept of recursive subroutines were introduced in the CS
>curriculum of that institution in that era). The instruction set is so
>elegant and the opcode formats so regular and predictable, that for
>years I could use the front panel switches (!) to key in an interrupt
>driven routine to echo keyboard input back to the TTY / CRT.
You know, when I was a lad, I had to live in a hole in the road, and
take a bath in the puddles when it rained. These youngsters today, they
don't know how easy they have it!
Seriously Randall, thats a fabulous story you have there. I've never
programmed anything via switches on the front. I think I should be
relieved to say that. Either your college was underfunded, or you are
older than I?
Roedy Green
<sn...@objmedia.demon.co.uk> wrote or quoted :
>Oh yeah, looked at that when I was doing my degree. Long time ago now.
>Never worked on PDP-11 assembler, but I noticed the similarity.
The PDP-11 started out simply enough when 64K seemed like infinite
RAM, but it got a little hairier once you tried to crack that barrier.
I'm pretty sure Kernighan and Ritchie must have had a PDP-11 in the
basement when they designed C. C maps onto its architecture so
smoothly.
When you are coding Intel assembler, even after a long familiarity,
you are always looking things up in the book. With PDP11 or 68K, you
just need a one page cheat sheet at most. Everything works pretty
must the way you would expect. The disadvantage is 68K assembler is
not quite as dense. As I recall, the only mildly tricky thing about
68K assembler is knowing when you will get sign extension and when
unsigned.
The thing that puzzles me is the complexity of the PowerPC and the
Itanium. I thought the world was going RISC. These machines have more
instructions than you could shake a stick at. Many of the Itanium
instructions I can't even think what on earth you would use them for.
The assembler I had most fun with was a PDP-8. I took a course on how
to build home brew interfaces. I first built a trivial little
interface that let me turn an LED on and off with the PDP-8. That was
the first time I had ever seen a computer have any direct effect on
the outside world, other than printing results. It tickled me no end
with the possibilities.
The assembler stuff I enjoyed most is writing device drivers.
One fun project was controlling all the lights and fans in a
department store chain, writing Univac's OCR reader driver (it reads
OCR and mark sense and you have a few milliseconds to decide which
pocket to put it in), an HDLC chip to build a home brew LAN,
a bidirectional parallel port between the PDP-11 and Apple ][, poking
UARTs, video card drivers, high speed square wave quadrature (position
sensing). It is fun to dip down in to pure electronics every once in
while, for example for a thermostat that automatically switches to a
lower setting when people go out or go to sleep
The best toy I ever had was a DEC MINC (a PDP-11 with fancy I/O
interfaces) and the BC Hydro solar energy research lab. However, the
DEC software made it TOO easy.
Roedy Green
<sn...@objmedia.demon.co.uk> wrote or quoted :
>Seriously Randall, thats a fabulous story you have there. I've never
>programmed anything via switches on the front. I think I should be
>relieved to say that. Either your college was underfunded, or you are
>older than I?
Entering short programs via boot switches was quite common up until
perhaps 1977.
Stephen Kellett
<ro...@mindprod.com> writes
>The PDP-11 started out simply enough when 64K seemed like infinite
>RAM, but it got a little hairier once you tried to crack that barrier.
64K, when I was a lad, I had 5K, well thats what Commodore advertised on
the box. Nasty marketing folks, I had 3.5K! 0.5K had gone to the screen
and the rest to the OS, but if you knew where the cassette read buffer
was you could poke a nifty assembler routine in there too. Vic=20 time!
Anyone else?
>When you are coding Intel assembler, even after a long familiarity,
>you are always looking things up in the book.
Oh yeah. Wrote my first (and only) game on the 80x286 in 1998 in my
lunch hour. I now use the Sybex 80386 book I bought in the same year, 15
years later. And you are right, I do look up the instructions on a
regular basis. Its a minefield, variable length instructions indeed.
>not quite as dense. As I recall, the only mildly tricky thing about
>68K assembler is knowing when you will get sign extension and when
>unsigned.
Yup, caught me out a treat porting the x86 game to the Atari ST.
>The thing that puzzles me is the complexity of the PowerPC and the
>Itanium. I thought the world was going RISC. These machines have more
Itanium, bluergh! I ported a huge Win32 CAD application to Win64 on
Itanium. Where is the stack? Er, its hidden. Where? Can't tell you. Why
not? Well, er, the register stack engine knows where it is. The what? We
don't want you munging about in the stack with your debuggery things, so
we've hidden the stack so the processors register renaming can really
much about with things. The stack, well its there, but we aren't telling
you where it is.
Horrible, Horrible, Horrible, from a debugging point of view.
Didn't help that my desktop Pentium could outpace the Itanium without
breaking into a sweat. Athlon 64 is the way to go. No competition there.
>instructions than you could shake a stick at. Many of the Itanium
>instructions I can't even think what on earth you would use them for.
RISC is a farce. The most RISC processor I've found is the 6502. 51
instructions (from memory). Lots of flexibility. 3 registers (A, X, Y).
Problem is, 6502 is a CISC, not a RISC.
>The best toy I ever had was a DEC MINC (a PDP-11 with fancy I/O
>interfaces) and the BC Hydro solar energy research lab. However, the
>DEC software made it TOO easy.
You make me feel young writing all that stuff. Wow!
Stephen Kellett
<ro...@mindprod.com> writes
>On Sat, 13 Sep 2003 23:44:17 +0100, Stephen Kellett
><sn...@objmedia.demon.co.uk> wrote or quoted :
>
>>Seriously Randall, thats a fabulous story you have there. I've never
>>programmed anything via switches on the front. I think I should be
>>relieved to say that. Either your college was underfunded, or you are
>>older than I?
>
>Entering short programs via boot switches was quite common up until
>perhaps 1977.
You are older than I. My first computer was a Vic-20, although I'd used
the school's Z80 based Research Machines and teacher's Trash-80 prior to
that. Hated the Z80 chip. Ugh. 8085 not much better. Awful instruction
set.
Roedy Green
<sn...@objmedia.demon.co.uk> wrote or quoted :
>Anyone else?
see http://mindprod.com/jgloss/equipment.html
My first personal computer had no RAM at all, just a lot of tubes and
a rotating drum. It had a few discrete transistors.
Radixsort was born waiting for it to compile.
See http://mindprod.com/jgloss/radixsort.html
David W. Hodgins
> In message <a467mvc43cqjdek5m...@4ax.com>, Roedy Green <ro...@mindprod.com> writes
>> The PDP-11 started out simply enough when 64K seemed like infinite
>> RAM, but it got a little hairier once you tried to crack that barrier.
>
> 64K, when I was a lad, I had 5K, well thats what Commodore advertised on the box. Nasty marketing folks, I had 3.5K! 0.5K had gone to the screen and the rest to the OS, but if you knew where the cassette read buffer was you could poke a nifty assembler routine in there too. Vic=20 time!
>
> Anyone else?
In High school, my first programming course was in Fortran on a Honeywell 100/5.
It had an optical card reader, punch card reader, card puncher, a printer, and two
disk drives. Taught myself asm, so I could disassemble the security system, and
modify it a little<g>. 16kb Ram, no registers. Everything done in ram. It had
a couple of switches on the front, that you could set physically, and check the
position of, in your program. Also had a single step button, so you could trace
through the instructions as they executed, using a small display on the front,
with inividual lights for each bit, showing the current instruction, and two
absolute addresses. If you pulled out a ram card, you could see the iron cores
for each bit. They were about a 64th of an inch in diameter. This was 1975.
Regards, Dave Hodgins
Randall R Schulz
Stephen Kellett wrote:
> In message <HyM8b.21296$dk4.6...@typhoon.sonic.net>, Randall R
> Schulz <rrsc...@cris.com> writes
>
>> I did learn PDP-11 assembly and wrote programs in it for one of
>> my undergraduate courses (among other things, this was the course
>> in which the concept of recursive subroutines were introduced in
>> the CS curriculum of that institution in that era). The
>> instruction set is so elegant and the opcode formats so regular
>> and predictable, that for years I could use the front panel
>> switches (!) to key in an interrupt driven routine to echo
>> keyboard input back to the TTY / CRT.
>
>
> You know, when I was a lad, I had to live in a hole in the road,
> and take a bath in the puddles when it rained. These youngsters
> today, they don't know how easy they have it!
Well, switches notwithstanding, MACRO-11 (the DEC-supplied assembler
for the PDP-11) was an amazing assembler (when that's one of your
primary programming tools, you make it good). I recall one assignment
where you could, given sufficient motivation and cleverness, get the
assembler to do all the computations needed and there was no need to
run any program--in fact, no instructions were emitted. I can't
remember what the program was supposed to do, unfortunately (I am,
as they say, older than dirt).
> Seriously Randall, thats a fabulous story you have there. I've
> never programmed anything via switches on the front. I think I
> should be relieved to say that. Either your college was
> underfunded, or you are older than I?
The University of Wisconsin certainly wasn't underfunded, but this was
the late 70s / early 80s. We had a PDP-11/20, a /40, a /45, a /34 and
eventually a VAX-11/780 and later a few /750s for distributed systems
research. The CS department also ran DEC's timesharing system (RSTS-E)
on a PDP-11/70. Back then, there was also a dual-processor Univac
mainframe and more than a few keypunches. I was back there a couple of
years ago, and the Univac machine room is now the campus computer
store and--are you ready for this?--there are no keypunches anywhere!
We used card input for our assembly programs on the 11/20, too, though
it did have a very low-res CRT and a keyboard. I guess there must have
been a line printer, too--maybe it spooled output through the Unix
system on the /45. The /20 had one of those head-per-track disk
drives, the /45 had two SMD drives (the ones that look like small
dishwashers or large trash compactors and shake like hell when the
system is driving them hard) for a grand total of 120 MB. Woo-Hoo!
I'm most proud of the time I fixed one of the Unibus serial cards (a
KL-11, maybe?) using a logic probe, a logic injector and the
schematics for the card. It was a bad 7400 series TTL chip (a hex
inverter, perhaps?).
Yeah, I guess we've come a long way. I guess... I miss all the
flashing lights. And nowadays you can't really fix much the way you
could back then. The PC board mounting technologies make it pretty
much impossible to replace components that aren't socketed.
If you want to see what crazy hardware is, check out DECtape:
<http://www.linuxguruz.com/foldoc/foldoc.php?query=DecTape>.
(We tried the swapping to DECtape hack they mention, by the way.)
Here's a page with pictures: <http://www.pdp8.net/tu56/tu56.shtml>.
> Stephen
Well, enough of this. The past is gone, may it rest in peace.
Randall
Chris Uppal
> Itanium, bluergh! I ported a huge Win32 CAD application to Win64 on
> Itanium. Where is the stack? Er, its hidden. Where? Can't tell you.
I know this is off-topic ;-) but how is garbage collection or any (other) form
of introspection on the stack, performed on such machines ?
To get back to the matter at hand, I could mention that I started out
programming with a paper tape reader and teletype, then progressed to punched
cards. It's true but misleading -- I only wrote 1.5* tiny programs then, and
didn't really start programming seriously until several years later on a
PDP/11, and some sort of Zilog box, with vi (et al) routinely available. I
guess I was spoilt.
-- chris
[*] Either 1 or 2 depending on whether you count programs *written* or programs
*run*. I still sometimes wonder whether that first program would have worked...
Stephen Kellett
<chris...@metagnostic.REMOVE-THIS.org> writes
>Stephen Kellett wrote:
>
>> Itanium, bluergh! I ported a huge Win32 CAD application to Win64 on
>> Itanium. Where is the stack? Er, its hidden. Where? Can't tell you.
>
>I know this is off-topic ;-) but how is garbage collection or any (other) form
>of introspection on the stack, performed on such machines ?
My description was a bit unfair. There are some instructions for finding
out where the stack is. However I don't think there is any concept of a
stack pointer, in the "normal" sense of the term.
Re: garbage collection for Java and Python etc. The lack of the ability
to walk an Itanium stack wouldn't be important, as you could easily
store the relevant information elsewhere. It would probably be important
if the Java was JITted and started to store data on the Itanium stack.
Roedy Green
<sn...@objmedia.demon.co.uk> wrote or quoted :
>Re: garbage collection for Java and Python etc. The lack of the ability
>to walk an Itanium stack wouldn't be important, as you could easily
>store the relevant information elsewhere. It would probably be important
>if the Java was JITted and started to store data on the Itanium stack.
For debugging you could pop the stack element by element to some RAM
and then push it back.
Sounds like they have, or plan soon to put, a variable size hardware
cache for the stack, with asynchronous save and restore of the
inactive parts to ram somewhere. This is what I was hoping some of
the stack machines of the 80s would do to make up for their lack of
registers.
Mitch Crane
news:0UmKH9Wpb6Y$Ew...@objmedia.demon.co.uk:
> 64K, when I was a lad, I had 5K, well thats what Commodore advertised
> on the box. Nasty marketing folks, I had 3.5K! 0.5K had gone to the
> screen and the rest to the OS, but if you knew where the cassette read
> buffer was you could poke a nifty assembler routine in there too.
> Vic=20 time!
>
> Anyone else?
Atari 800! Advertised as 48k (they were nice and didn't count the 16k
ROM). Started out with basic. You could could move sprites horizontally
with a simple poke, but to move them vertically required moving the
bits, so I wrote a vertical blank interrupt routine to move the sprites
vertically (stuffed in good ol' page 6--0x0600-0x06ff). After getting a
taste of RAW speed I ran out and bought a copy of the Mac65 assembler.
>>instructions than you could shake a stick at. Many of the Itanium
>>instructions I can't even think what on earth you would use them for.
>
> RISC is a farce. The most RISC processor I've found is the 6502. 51
> instructions (from memory). Lots of flexibility. 3 registers (A, X,
> Y). Problem is, 6502 is a CISC, not a RISC.
I've often though about that. I'd like to see what a 6502 instruction
set processor built using 2003 technology could do... just for fun.
--
ybbxvatyvxrnobeantnvayvivatyvxrnurergvpyvfgravatgbneguheyrrerpbeqfznxv
atnyylbhesevraqfsrryfbthvyglnobhggurveplavpvfznaqgurerfgbsgurvetrareng
vbaabgriragurtbireazragnertbaanfgbclbhabjohgnerlbhernqlgborurnegoebxra
Stephen Kellett
Crane <a-...@a-two.a-three> writes
>Atari 800! Advertised as 48k (they were nice and didn't count the 16k
>ROM). Started out with basic. You could could move sprites horizontally
>with a simple poke, but to move them vertically required moving the
>bits, so I wrote a vertical blank interrupt routine to move the sprites
>vertically (stuffed in good ol' page 6--0x0600-0x06ff). After getting a
>taste of RAW speed I ran out and bought a copy of the Mac65 assembler.
I had an Atari 400 years later (for porting a game to). VBL interrupts
and the HBL ones so you could get one line a particular colour. Those
were the days! I bet most 20 years olds are "what the F? is he talking
about?"
I wrote the game on a BBC Micro in 6502 assembler (*). Hand made
parallel connection from the BBC to two of the joystick ports configured
to receive 4 bits each. I had to type the assembly code into the Atari
keyboard (membrane) as a basic routine poking into memory to get the
code across from the beeb. No debugger - all debugging was printing a
character to the top left corner (that advanced huh?). Make a mistake
with the download code and you'd have to start again.
(*) The game was on C64, Atari400/800,C16,Acorn BBC Micro, then the
company went bust, and I wrote it for the Atari ST, and in my lunch
break in my next job for the IBM PC AT in 80286, just to prove I could
get my head around both 68K and x86 (which have the operands in
differing orders to each other). The game never saw the light of day,
and I was legally prevented from giving away the ST and PC versions as
the liquidators stated I had "prior knowledge".
>I've often though about that. I'd like to see what a 6502 instruction
>set processor built using 2003 technology could do... just for fun.
It'd be awesome, although with such few registers you'd waste a lot of
time waiting for the RAM. They did build a 16-bit 6502 (if you can
imagine that), can't remember its name, never used it. Wasn't too
successful in the marketplace.
Mitch Crane
$Ew...@objmedia.demon.co.uk:
> In message <Xns93FA561083E4E61...@216.196.97.132>, Mitch
> Crane <a-...@a-two.a-three> writes
>>Atari 800! Advertised as 48k (they were nice and didn't count the 16k
>>ROM). Started out with basic. You could could move sprites horizontally
>>with a simple poke, but to move them vertically required moving the
>>bits, so I wrote a vertical blank interrupt routine to move the sprites
>>vertically (stuffed in good ol' page 6--0x0600-0x06ff). After getting a
>>taste of RAW speed I ran out and bought a copy of the Mac65 assembler.
>
> I had an Atari 400 years later (for porting a game to). VBL interrupts
> and the HBL ones so you could get one line a particular colour. Those
> were the days! I bet most 20 years olds are "what the F? is he talking
> about?"
Yeah, and so you could cheat and get tons (relatively speaking) of colors
on the screen or make one sprite do the duty of several. It was way cool.
> I wrote the game on a BBC Micro in 6502 assembler (*). Hand made
> parallel connection from the BBC to two of the joystick ports
> configured to receive 4 bits each.
Yeah, that was another cool feature--using the joystick ports for output
as well as input.
>>I've often though about that. I'd like to see what a 6502 instruction
>>set processor built using 2003 technology could do... just for fun.
>
> It'd be awesome, although with such few registers you'd waste a lot of
> time waiting for the RAM. They did build a 16-bit 6502 (if you can
> imagine that), can't remember its name, never used it. Wasn't too
> successful in the marketplace.
I believe that was the 65816 which was used in the Apple IIgs and maybe
the Super NES game console.
--
ybbxvatyvxrnobeantnvayvivatyvxrnurergvpyvfgravatgbneguheyrrerpbeqfznxv
atnyylbhesevraqfsrryfbthvyglnobhggurveplavpvfznaqgurerfgbsgurvetrareng
vbaabgriragurtbireazragnertbaanfgbclbhabjohgnerlbhernqlgborurnegoebxra
Wee Jin Goh
much simpler architecture than x86, and you've got a simulator called
SPIM (http://www.cs.wisc.edu/~larus/spim.html) that you can download and
play with. I used it when I was doing a computer hardware module at
university.
Regards,
Wee Jin
Bob Donahue
The manufactures used to make evaluation kits for these micros. The kits
usually had 6 digit displays (4 digits for address and 2 digits for data)
and a small keyboard. I'd stay away from the new 'RISC' micros. RISC might
be good for high level language, but it's terrible for assembly language.
--
Bob D.
"Stephen Kellett" <sn...@objmedia.demon.co.uk> wrote in message
news:PWcknjTB35Y$Ew...@objmedia.demon.co.uk...
John W Kennedy
> I recommend starting out with an 8 bit micro like the 6800, 8080, or 6502.
> The manufactures used to make evaluation kits for these micros. The kits
> usually had 6 digit displays (4 digits for address and 2 digits for data)
> and a small keyboard. I'd stay away from the new 'RISC' micros. RISC might
> be good for high level language, but it's terrible for assembly language.
Heck, if you want to go with antiques, go to bitsavers.org and get the
manuals for the old IBM 1401. Easiest machine language / assembler
languages ever made, and there are emulators available.
--
John W. Kennedy
"The poor have sometimes objected to being governed badly; the rich have
always objected to being governed at all."
-- G. K. Chesterton. "The Man Who Was Thursday"
Roedy Green
<jwk...@attglobal.net> wrote, quoted or indirectly quoted someone who
said :
>Heck, if you want to go with antiques, go to bitsavers.org and get the
>manuals for the old IBM 1401. Easiest machine language / assembler
>languages ever made, and there are emulators available.
One of the easiest assemblers I ever programmed with the 68000 used in
the early Macs. Intel has all kinds of asymmetry and magic registers
with special properties. You not only have the machine to understand
but dozens of pseudo-ops to deal with the addressing. I don't know how
compiler writers ever generate code for them.
You might pick up an old Mac free, and find the software to let you
play.
For just learning, some of the simulators used at universities to
teach assembler might be available. They typically have some
unrealistic but very useful instructions to make life easy for the
novice.
PDP 11 assembler is very straight forward. C is almost an assembler
for it.
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
Joshua Cranmer
> I recommend starting out with an 8 bit micro like the 6800, 8080, or 6502.
> The manufactures used to make evaluation kits for these micros. The kits
> usually had 6 digit displays (4 digits for address and 2 digits for data)
> and a small keyboard. I'd stay away from the new 'RISC' micros. RISC might
> be good for high level language, but it's terrible for assembly language.
In my microprocessor course, we used the MC6800. If you're actually
wiring together a circuit, given the anecdotal evidence I've heard, the
6800 is your best bet. Definitely better than the 8080.
/me goes off and grouses about the difficult of getting those thin wires
to stack...
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
Laurent D.A.M. MENTEN
surprised by ARM's instruction set elegance and power (like any
instruction, even arithmetic, can be conditional)...
Bob Donahue a écrit :
Roedy Green
<laurent...@teledisnet.be> wrote, quoted or indirectly quoted
someone who said :
>Digging a bit in NintendoDS home-brew development I found myself nicely
>surprised by ARM's instruction set elegance and power (like any
>instruction, even arithmetic, can be conditional)...
Another architecture I really liked was the PowerPC, but I never
actually wrote code for it. I was sad to see Apple abandon it.
Intel's Itanium is incredibly complicated and has not seemed to catch
on. So we are stuck with the Intel architecture which was essentially
nailed down at the time of the XT. It needs a major overhaul.
John W Kennedy
> On Sat, 26 Apr 2008 17:50:42 +0200, "Laurent D.A.M. MENTEN"
> <laurent...@teledisnet.be> wrote, quoted or indirectly quoted
> someone who said :
>
>> Digging a bit in NintendoDS home-brew development I found myself nicely
>> surprised by ARM's instruction set elegance and power (like any
>> instruction, even arithmetic, can be conditional)...
>
> Another architecture I really liked was the PowerPC, but I never
> actually wrote code for it. I was sad to see Apple abandon it.
They may not have. Apple just purchased a PowerPC fabricator.
--
John W. Kennedy
"Never try to take over the international economy based on a radical
feminist agenda if you're not sure your leader isn't a transvestite."
-- David Misch: "She-Spies", "While You Were Out"