World: r3wp

Nope on the creep;  A DSL will be the outcome of the lecture.  I'm 
leaning either toward a password management dialect or a (simple) 
file management command set.

great, looking forward to it

A bit related, which might be a help in understanding parse in any 
way:

I want to know. how fast rebcode is at emulating CPUs, so I'm developing 
a 6502 assembler using parse and want to emulate the 6502 CPU using 
rebcode at a later time. When the assembler is more finished, I'll 
release it with a GPL license. It's basically a bunch of parse rules.

James is getting into Forth, and I was just looking at some old notes 
I made on ForthR (play on "further"), where the machine primitives 
are actually a little REBOL VM/emulator, rather than ASM for a specific 
chip. Easier to get started, though not real Forth.

I've always thought we should have examples of how languages can 
be implemented in REBOL.

I have the figforth assembly code for the 6502  ... so you could 
run fig forth on your 6502 emulator ?

Yeah, let me see where I put that... :-)

I'm not really sure. First I do a general 6502 assembler and emulator, 
but I only have an emulator of the BBC homecomputer to test up against, 
so I probably have to deal with some Operating System stuff too. 
I operate with a 64k address space, and on the BBC writing to some 
certain addresses made something special for that platform happen. 
But let's see, what we can do.

slightly off topic: who was it that wrote a z80 emulator with embedded 
space invaders?

Steeve, and it was Galaga.

there should be some follow up on it. it's been forgotten a bit

I'm not sure that it would be a good idea to make new rebcode projects 
until rebcode is reintroduced, unless the purpose of the project 
is to provide reference data for the redesign of rebcode.

yes something like that. I wouldn't expect it for a second to run 
on R3, even if Rebcode goes in. but I think it makes a good chuck 
of code for rebcode testing.

I had the impression, that it was most the names of the rebcodes, 
that would change. Then it should be too much work to port existing 
rebcode over.

shouldn't

Remember: Rebcode redesign. Lots of legacy code is not a good idea 
unless noone has a problem with it not running on the new version. 
There are a lot of problems with the current design, and it seems 
likely that there will be changes to the semantics, not the names.

The current design doesn't provide that much of a speedup over regular 
R3 code, mostly because of the stack variable change.

ok

I'm on the parsing assembler part, so no rebcode yet here.

So... the trick in RebCode for using it in R3 is how to efficiently 
access variables.

In R3 variables are more protected than in R2.  But, perhaps we can 
do something with temporaries on stack that require fewer tests, 
but have limited usage patterns.

But weeee want RebCode. Hopefully it comes. Even if slower than R2 
version. We will see - maybe C based plug-ins and proper porting 
efforts have more sense, dunno ...

I finished v. 1.0.0 of 6502 assembler: http://www.fys.ku.dk/~niclasen/rebol/language/asm6502.r

It defines the asm6502 function, which take 6502 assembler as text 
input and produces 6502 machine code (opcodes). Might be a good example 
of parsing in REBOL.

Go John Go!

:)

Oh ...I thought we were going to see a 6502 emulator!

One step at a time!

single stepping?

Yeah, I'm only a level 1multitasker or so.

You see, now I have a 6502 assembler written in REBOL, so now it 
will be easy for me to test a 6502 emulator, while I'm writing it.

I've found, that it's best to test while I develop. It's traditionally 
design-programming-test. I don't find this the best way, if you want 
fast progress and few errors.

Agreed;  write a line, test a line.  

Personal comment:

Then forget you wrote it so a few days later you can  write a line, 
test a line and then go "whoa, deja-vu"  :)

Since it's line-based, could the syntax error tell you which line, 
in addition to what op it's near?

Yes, for the syntax errors it's fixed now: http://www.fys.ku.dk/~niclasen/rebol/language/asm6502.r

For labels not found, you have to search you source, where you branch 
to that label.

It's a one pass assembler and then some. After first pass, it checks, 
if there is forward referencing to labels and then fix those relative 
addresses directly in the produced code. Should be fast, as it's 
not a completely two-pass.

I haven't played with it, but it's still veyr impressive for such 
a short project.

It's about 10k REBOL source. 2644 bytes compressed.

It amuses me to use REBOL for things like this. The most enjoyable 
language around! It took me like 3 halves evenings.

Elite, John.  Elite.

Instructions can be separated by : on the same line, and comments 
put at the end. Example:
asm6502 "inx:iny This is a comment!"
UPPER/lower case can be used:
asm6502 "INX : INY This is a comment!"

btiffin, hehe :)

The asm6502 can take the refinement /at to tell the starting address 
in the 64kb ram area for the produced code. I don't like the refinement 
being called /at, because we already have the word AT. Any suggestions 
for a better name?

The Program Counter get set to the argument for that refinement, 
else 1, if the refinement isn't there.

So it could be named something like: /pc /target /address /start 
...

/begin maybe?

Or I should just stick with /at, because that's the word, we usually 
use to position ourselves within a series. (And the ram can be seen 
as a series.)

/skip would be the rebolious name I think, but /org would resonate 
with me as well.

Elite was done on the C64 as well as other computers of that era, 
so would have been done in 6502 assembler.

Yes! :)
From http://www.bbcmicrogames.com/acornsoft.html

It has been ported to just about every other platform out there however, 
it appeared first on the BBC.

The BBC had a 6502 too, and it's the platform, I'm testing up against, 
so let's hope, it all work out well.

/at is probably fine.

Is there an emulator for this Elite release?