Aquarius Bitmap Graphics Tool

[+MattelAquarius]

I've been playing around this morning.

 

For some reason, the attached file causes an error on the Aquarius, when the conversion program is run.

 

It also gives some strange color output before the crash. I'm not sure what I did to the pic to cause it. Attached it, in case you're curious.

 

 

I can't recreate the error - I saved the file, ran the converter and it ran fine?

 

That's odd. I've run it several times, and it always produces the same file, and that file always results in an error message on line 24, just before it would've finished. The exact type of error is unknown, because the message gets corrupted.

 

I've attached the output file for your examination. I wonder if it will work on your VAQ.

 

Note: Had to zip it, because AA doesn't like .txt attachments, apparently.

7800BallBlazergame.zip

[+MattelAquarius]

Before:

 

 

After:

[chjmartin2]

I figured out the problem. One of the lines is too long to be typed in as a program. Line 58 ended up too long because there were so many two digit numbers. It is set up to do 22 values per data line. Amazing that it took this long to find it with so many conversions I have done. I will change the program to do 10 sets of 2 per line and that will fix it right up. I'll post it in a few.

[chjmartin2]

Fixed Version.

BMPAQV3.zip

[+MattelAquarius]

Fixed Version.

 

 

You're right, it hasn't been a problem; it just struck me as strange. I thought I may have broken the internets.

 

Thanks for the fix.

[+MattelAquarius]

I like this one.

 

Before:

 

 

After:

[mvdsteenoven]

Figure out how to get the data compressed enough to run on a stock aquarius

 

The DATA lines are taking a lot of memory space, so I was thinking maybe it is possible to put the screendumps into an array. So I have written a VBScript that reads the output from your program and creates an array file for the VirtualAquarius (_A.CAQ)

Then I created a BASIC program that loads the array and copies everything to screen (LDSCRN_BAS.CAQ).

But the arrays needs to hold 1920 bytes, which is more then the 1,7K free memory inside the stock Aquarius.

So I've written something in machinecode that loads the array from tape and writes it directly to screen (LDSCRN-USR_BAS.CAQ).

I have only tested these programs on Virtual Aquarius, but it seems to work.

 

Regs,

Martin

ldscrn.zip

[chjmartin2]

Figure out how to get the data compressed enough to run on a stock aquarius

 

The DATA lines are taking a lot of memory space, so I was thinking maybe it is possible to put the screendumps into an array. So I have written a VBScript that reads the output from your program and creates an array file for the VirtualAquarius (_A.CAQ)

Then I created a BASIC program that loads the array and copies everything to screen (LDSCRN_BAS.CAQ).

But the arrays needs to hold 1920 bytes, which is more then the 1,7K free memory inside the stock Aquarius.

So I've written something in machinecode that loads the array from tape and writes it directly to screen (LDSCRN-USR_BAS.CAQ).

I have only tested these programs on Virtual Aquarius, but it seems to work.

 

Regs,

Martin

 

Wow.... now that is BAD ASS... I couldn't do that myself. I can't wait to try it.... nice job!!!

[chjmartin2]

I cannot get your VBS script to work. I am getting an error that says:

 

 

I am frustrated because it looks like your program really helps with the memory issue in basic. Any thoughts? What does the script do? Maybe I could modify my converter to output the right format.

 

I am not worthy... I bow down... I just want to be able to make your post converter work!

[chjmartin2]

I cannot get your VBS script to work. I am getting an error that says:

 

 

I am frustrated because it looks like your program really helps with the memory issue in basic. Any thoughts? What does the script do? Maybe I could modify my converter to output the right format.

 

I am not worthy... I bow down... I just want to be able to make your post converter work!

 

 

Fantastic job. Really really fantastic. Very jealous at your superior knowledge of ASM. I am going to try to dissect your script in order to allow the converter to output the appropriate CAQ file for the converter. I think I will let the user choose the .AQ file or the .CAQ file and I can also pack it with the loader. Fantastic job. I will try it on a real aquarius tonight and post screen shots.

 

Truth be told, I have really wanted to learn ASM especially for my ongoing Aquarius projects. If your screen loads as fast on a real AQ as it does on the emulator (I even turned off the speed up when accessing files option) then there is a really good chance that we can create some hacked video modes.

 

Emucompboy said that maybe we could chase the beam down the screen and change characters in the middle of it being drawn and try to get multiple characters/colors per block. It would be a memory hog, but still cool even if we had to use a memory expander. It would probably require loading the array into memory and definately would require machine code to accomplish it. Even if we couldn't get color and character to switch on the fly, maybe just character.

 

Picture this (easiest scenario) you draw the top half of the characters across the screen, and before the beam gets done with the 4th line you change the characters for the next 4 lines, and on and on until you get to the end of the screen. It may require an endless loop because once the screen redraws it'll revert to the other characters again. If the memory movements are quick enough it just might work. What I don't know is if the VDG is picky and won't allow you to change characters on the fly. (i.e. does it wait for a character to be fully loaded.)

 

Problem is - I have no idea how to go about accomplishing this, but taken to its eventual end, you might be able to create a screen of 1x8 blocks with each block having 2 colors and ALMOST any combination of dots that you want. You'd get a seperate set of potential blocks for each character, the first row would be the top of each character, 2nd would be second and you'd have repeats every 8 rows. Think Semigraphics modes on the TRS-80. This would allow for almost a 320x192x16 color bitmap to be displayed. I could write the image processor and converter, but have no shot at this point in tricking out the aquarius. Thoughts?

[chjmartin2]

I cannot get your VBS script to work. I am getting an error that says:

 

 

I am frustrated because it looks like your program really helps with the memory issue in basic. Any thoughts? What does the script do? Maybe I could modify my converter to output the right format.

 

I am not worthy... I bow down... I just want to be able to make your post converter work!

 

Need to run the script as an administrator if you are running Windows 7.

[chjmartin2]

This is really exciting. I didn't realize that the CAQ file format was so simple. I think I could easily implement CAQ file output into the program and combining it with the loader it will be great. Will provide some nice output options (BASIC only, Array+BASIC Loader, Array+ASM Loader.) Can't say enough good things. Stinks that I am at work and can't really work on it.

[chjmartin2]

Figure out how to get the data compressed enough to run on a stock aquarius

 

The DATA lines are taking a lot of memory space, so I was thinking maybe it is possible to put the screendumps into an array. So I have written a VBScript that reads the output from your program and creates an array file for the VirtualAquarius (_A.CAQ)

Then I created a BASIC program that loads the array and copies everything to screen (LDSCRN_BAS.CAQ).

But the arrays needs to hold 1920 bytes, which is more then the 1,7K free memory inside the stock Aquarius.

So I've written something in machinecode that loads the array from tape and writes it directly to screen (LDSCRN-USR_BAS.CAQ).

I have only tested these programs on Virtual Aquarius, but it seems to work.

 

Regs,

Martin

 

Martin,

 

I am looking at your basic loader and I see that you have an Array of 480. How are you packing the data? You said 1920 bytes for a screen - that's easy - 40x24x2, one byte for character and the other for color. (256 characters and 64 color combinations) Anyway, If I take 1920/480 I get 4, but that still confuses me. It looks like you are bit packing the data, but I can't decipher how...

[mvdsteenoven]

Sorry for not coming back earlier, but today was just a working day for me too. I am happy to see that you like my suggestions.

 

I cannot get your VBS script to work. I am getting an error that says:

The problem with vbScript is that I am using an ActiveX that is only available in Windows XP, but not in Vista or Windows 7. I have added a modified version. Now you can open an Explorer and drag-and-drop the .AQ BASIC file on the ConvertDATA_v2.vbs

 

Emucompboy said that maybe we could chase the beam down the screen and change characters in the middle of it being drawn and try to get multiple characters/colors per block.

I have added a third version; called CPYSCR_BAS.CAQ

In the first LDSCRN version I used BASIC to copy the array to the screen.

The third version is similar to the first version, but using machinecode to copy the contents to screen (see CopyScrn.asm)

As you will see the Aquarius can copy fast enough without any tricks.

BTW.. The screendump is stored as Char1, color1, char2, color2, ...., char960, color960. If I stored them as char1, char2, ...., char960, color1, color2, ...., color960 then we could have copied even faster.

 

NOTE: these programs have no "intelligence", they have been written for these situations.

The programs expects that the first array in memory is the array containing the screendump.

You might also noticed in the first LDSCRN version that I have initialized all variables at line #5. This is necessary as the array is moved in memory whenever a new variable is created. Also FOR...NEXT loops seem to have an effect on the array in memory.

I have also initialized the variables in CPYSCR, but this not necessary as the machinecode handles the copy procedure. It is just a leftover of the first version.

 

How are you packing the data? [ .... ] It looks like you are bit packing the data, but I can't decipher how...

Oke, about Aquarius array handling;

Aquarius BASIC uses 4 bytes to store a number. If we create an array that could hold 1920 numbers then we would create the array using DIM A(1919) (.. remember A(0) is also used ..).

In this case we can easily store numbers in the array, like A(0)=peek(12328), A(1)=peek(12329), and so on. But it would use 4 * 1920 = 7680 bytes.

 

Now the moment you do a DIM a(479) the system reserves 4*480 = 1920 bytes memory, continued space (as in not framented).

So, like the machinecoded games by AddOn, I have abused this area. I am not using the array as numbers, but as a memory area from which I can PEEK the characters and colors.

 

As you've noticed the CAQ format for arrays is very simple, but the number of bytes must be dividable by 4 (hence, 4 bytes to store a number).

 

Please let me know if you have more questions.

 

Regs,

Martin

ldscrn_v2.zip

[mvdsteenoven]

Fantastic job. Really really fantastic. Very jealous at your superior knowledge of ASM.

I couldn't do it without my book

 

Z80 Assembly Language Subroutines

Leventhal, Lance A. & Saville, Winthrop

Osborne/McGraw-Hill, 1983. - XI, 497 p.

ISBN 0-07-931091-5

 

and the Aquarius ROM disassembly by Kenny Millar, available at the Yahoo groups.

[chjmartin2]

Sorry for not coming back earlier, but today was just a working day for me too. I am happy to see that you like my suggestions.

 

I cannot get your VBS script to work. I am getting an error that says:

The problem with vbScript is that I am using an ActiveX that is only available in Windows XP, but not in Vista or Windows 7. I have added a modified version. Now you can open an Explorer and drag-and-drop the .AQ BASIC file on the ConvertDATA_v2.vbs

 

Emucompboy said that maybe we could chase the beam down the screen and change characters in the middle of it being drawn and try to get multiple characters/colors per block.

I have added a third version; called CPYSCR_BAS.CAQ

In the first LDSCRN version I used BASIC to copy the array to the screen.

The third version is similar to the first version, but using machinecode to copy the contents to screen (see CopyScrn.asm)

As you will see the Aquarius can copy fast enough without any tricks.

BTW.. The screendump is stored as Char1, color1, char2, color2, ...., char960, color960. If I stored them as char1, char2, ...., char960, color1, color2, ...., color960 then we could have copied even faster.

 

NOTE: these programs have no "intelligence", they have been written for these situations.

The programs expects that the first array in memory is the array containing the screendump.

You might also noticed in the first LDSCRN version that I have initialized all variables at line #5. This is necessary as the array is moved in memory whenever a new variable is created. Also FOR...NEXT loops seem to have an effect on the array in memory.

I have also initialized the variables in CPYSCR, but this not necessary as the machinecode handles the copy procedure. It is just a leftover of the first version.

 

How are you packing the data? [ .... ] It looks like you are bit packing the data, but I can't decipher how...

Oke, about Aquarius array handling;

Aquarius BASIC uses 4 bytes to store a number. If we create an array that could hold 1920 numbers then we would create the array using DIM A(1919) (.. remember A(0) is also used ..).

In this case we can easily store numbers in the array, like A(0)=peek(12328), A(1)=peek(12329), and so on. But it would use 4 * 1920 = 7680 bytes.

 

Now the moment you do a DIM a(479) the system reserves 4*480 = 1920 bytes memory, continued space (as in not framented).

So, like the machinecoded games by AddOn, I have abused this area. I am not using the array as numbers, but as a memory area from which I can PEEK the characters and colors.

 

As you've noticed the CAQ format for arrays is very simple, but the number of bytes must be dividable by 4 (hence, 4 bytes to store a number).

 

Please let me know if you have more questions.

 

Regs,

Martin

 

There are two fantastic ideas that come out of this for me. The program that is copying from memory makes me want to make two images and rapidly flash them back and forth to create flicker colors. This would roughly give a palette of 64 colors to choose from. 80x72x64 might make some decent pictures. I wonder how back the flicker would be on the screen. The timing would also be interesting because you would at least want it to show one image on the even field and the other on the odd field. 29.97 frames per second would be 59.94 fields per second, so you would have to draw one field every 16.7 million nanoseconds - that should be plenty of time I think.

 

The second idea would be to create 2 character matrices and 2 color matrices and load them in time with the beam as it draws the even frame and then load them again as it draws the odd frame. Your programs are really going to help me.

 

So I understand, the data statement at the begining of the CPYSCR is the output of the compiled COPYSCRN.ASM? All this machine language is new to me - somehow those are the opcodes as byte values?

 

I think the flicker idea would be easier to implement, but the first passion was to try to get more apparent resolution. I need to learn ASM - so I can really modify your code and be successful. Thanks for your input, I will definitely need help when I get stuck!

[mvdsteenoven]

So I understand, the data statement at the begining of the CPYSCR is the output of the compiled COPYSCRN.ASM? All this machine language is new to me - somehow those are the opcodes as byte values?

 

Yep, after you have compiled the assembly file (tasm -80 -b copyscrn.asm) it will create an OBJ file.

You need to POKE these bytes somewhere into free memory (in this case at address 16912)

Then memory location 14340 plus memory location 14341 * 256 needs to point to this start address

50 POKE14341,INT(16912/256):POKE14340,16912-256*PEEK(14341)

When you execute X=USR(0) it will call the procedure at this memory address.

 

The attached vbscript will convert the OBJ file into DATA lines

cscript //nologo obj2Data.vbs copyscrn.obj

 

BTW In the previous BASIC file ldscrn-usr_bas.caq I have "embedded" the machinecode into the BASIC program, by creating the first BASIC line as

 5 REM {...machinecode...}

OldSkool

 

This is the reason why you see all this strange characters while the program still works. But this first version is using all relative jumps, so it doesn't matter where the machine code is located in memory. In the second program I am calling a subroutine which I have created myself. Since I need to know where the subroutine is located in memory, as an absolute address, I had to make sure that all the machinecode is on a fixed location.

 

Does this still make sense?

obj2Data.zip

[mvdsteenoven]

There are two fantastic ideas that come out of this for me.

Or you could create a background screen like 160 wide by 20 height, and pan the background left and right as your character is moving around.

(Thought of this when I saw Jason's Kings Quest screen)

[chjmartin2]

Assembler is so hard. All I wanted to do was to write a program that displays a single character on the entire screen and man, I couldn't do it.

 

Here is my code:

 

; File: TEST.ASM

; Displays a few things on the screen.

;

; Use tasm (supplied with VirtualAquarius) to compile:

; tasm -80 -b test.asm

;

 

.ORG 16912

 

ld HL, 12328 ; start address characters

ld DE, 13288 ; end address characters

 

 

loop:

ld hl,$23 ; Write # out to screen

inc hl ; Move up one

 

jr loop ;repeat

 

.END

 

Don't laugh... but what am I doing wrong?

[jaybird3rd]

Don't laugh... but what am I doing wrong?

No laughing here; assembly takes some getting used to if you're accustomed to working in high-level languages. The instructions are very simple, but you have to keep track of more of the details of what's going on inside the CPU and memory.

 

In your main loop, you're writing the value $23 into the register pair HL rather than into the memory location referenced by HL; for the latter, you'll need to enclose the HL in parentheses. This "fill" routine, which fills either the character or color matrix with a single value, will do what you need:

 

fill: ld de,$03ff ; Use register DE as a byte counter (there are 1024 bytes in both matrices)

loop: ld (hl),b   ; Fill current location in the matrix with character/color code
     inc hl      ; Move to next location in the matrix
     dec de      ; Decrement byte counter
     ld a,d      ; Check to see if byte counter has reached zero
     or e
     jr nz,loop  ; If byte counter is non-zero, repeat loop
     ret         ; If byte counter is zero, exit routine and return

Before calling this routine, just store the top address of the matrix you want to fill ($3000 for the character matrix or $3400 for the color matrix) into register pair HL, and the code you want to fill it with (the character or color code) into register B.

 

It's pretty self-explanatory, except perhaps for the fourth and fifth lines of the loop (the "check for zero" step). The character and color matrices are both 1024 bytes (1K) in size, which is why we need to use a 16-bit register pair for the counter; in this case, we're using the register pair DE. To check to see if the counter has reached zero, we load one half of DE into the accumulator and then perform a logical OR with the other half (it's necessary to do it this way because the accumulator is only an 8-bit register). If both halves of the counter are equal to zero, this will result in a zero flag, which is then checked by the conditional relative jump (in line six).

 

Using this routine, you can fill the screen with characters or colors almost instantly; using a comparable routine written in BASIC (using POKE statements), the fill would take several seconds to complete.

[chjmartin2]

Wow... So I figured out how to get the fill routine to work, but I cannot seem to get the syntax right to invoke it in a loop. Here is what I am trying. Why can't I just set the b register to the color set, set HL to the color address, call fill then reset b to another color and call fill again, then go ahead and repeat that until infinity. When I run it, it reboots the system. I want to swap between colors as fast as possible. I appreciate all of the help - if I can bust through this learning curve, I am positive I will be able to do some awesome graphics.

 

; File: TEST.ASM

; Displays a few things on the screen.

;

; Use tasm (supplied with VirtualAquarius) to compile:

; tasm -80 -b test.asm

;

 

main:

ld b, $55 ; set register b to color set 55

ld hl, $3400 ; set memory location to color video

call fill ; fill er up

ld b, $72 ; set register b to color set 72

call fill ; fill er up

jp main ; go back to main

 

fill: ld de,$03ff ; Use register DE as a byte counter

 

loop: ld (hl),b ; Fill current location in the matrix with character color code

inc hl ; Move to next location in the matrix

dec de ; Decrement byte counter

ld a,d ; Check to see if byte counter has reached zero

or e

jr nz,loop ; If byte counter is non-zero, repeat loop

 

ret ; If byte counter is zero, finish loop and return

 

.END

[catsfolly]

Wow... So I figured out how to get the fill routine to work, but I cannot seem to get the syntax right to invoke it in a loop. Here is what I am trying. Why can't I just set the b register to the color set, set HL to the color address, call fill then reset b to another color and call fill again, then go ahead and repeat that until infinity. When I run it, it reboots the system. I want to swap between colors as fast as possible. I appreciate all of the help - if I can bust through this learning curve, I am positive I will be able to do some awesome graphics.

 

; File: TEST.ASM

; Displays a few things on the screen.

;

; Use tasm (supplied with VirtualAquarius) to compile:

; tasm -80 -b test.asm

;

 

main:

ld b, $55 ; set register b to color set 55

ld hl, $3400 ; set memory location to color video

call fill ; fill er up

ld b, $72 ; set register b to color set 72

call fill ; fill er up

jp main ; go back to main

 

fill: ld de,$03ff ; Use register DE as a byte counter

 

loop: ld (hl),b ; Fill current location in the matrix with character color code

inc hl ; Move to next location in the matrix

dec de ; Decrement byte counter

ld a,d ; Check to see if byte counter has reached zero

or e

jr nz,loop ; If byte counter is non-zero, repeat loop

 

ret ; If byte counter is zero, finish loop and return

 

.END

 

The fill subroutine changes the value of hl, so you need to load these registers again:

  
       ld b, $55		; set register b to color set 55
ld hl, $3400	        ; set memory location to color video
call fill		; fill er up
ld b, $72		; set register b to color set 72
       ld hl, $3400	        ; set memory location to color video AGAIN
call fill		; fill er up
jp main		        ; go back to main

 

That might work better.

[chjmartin2]

I am banging my head against the wall here... This should just set the entire screen to color 5 and then the entire screen to color 8. It doesn't do either of those things. I hope y'all stay patient with me.

 

 

 

; File: TEST.ASM

; Displays a few things on the screen.

;

; Use tasm (supplied with VirtualAquarius) to compile:

; tasm -80 -b test.asm

;

 

main:

 

ld hl, $3400 ; set memory location to color video

ld b, $5 ; set register b to color set 55

Call fill ; fill er up

 

ld hl, $3400 ; reset memory location to color video

ld b, $8 ; set register b to color set 75

Call fill ; fill er up

RET

 

fill:ld de,$03ff ; Use register DE as a byte counter

 

loop:ld (hl),b ; Fill current location in the matrix with character color code

inc hl ; Move to next location in the matrix

dec de ; Decrement byte counter

ld a,d ; Check to see if byte counter has reached zero

or e

jr nz,loop ; If byte counter is non-zero, repeat loop

 

ret ; If byte counter is zero, finish loop and return

 

.END

[jaybird3rd]

I've never used assembly language routines from within Aquarius BASIC, so I can't say whether you're handling that part correctly, but the code above looks fine to me. I do notice that you're not setting a starting address, though.

 

For short assembly routines like this, I generally find it helpful to test my code as a quick little cartridge binary; once I'm sure it's working as standalone code, I can then integrate it into a larger program.

 

Here is a slightly modified version of your program; it fills the screen with character $C8 and color $31, creating a yellow-on-red "grid pattern":

 

.org $E010

main

ld	hl,$3400
ld	b,$31
call	fill

ld	hl,$3000
ld	b,$C8
call	fill

halt

fill

ld	de,$03ff

loop

ld	(hl),b
inc	hl
dec	de
ld	a,d
or	e
jr	nz,loop

ret

.end

To create a cartridge binary, just set the starting address to $E010 (as I've done here) and compile. You'll then need to add a valid sixteen-byte header to your binary before the Aquarius will load it as a cartridge image (it's a very weak form of "security").

 

First, compile the code:

 

TASM -80 -B FILL.ASM FILL.BIN

 

Then, prepend the cartridge header to your binary:

 

COPY /B CARTHEAD.BIN+FILL.BIN FILL2.BIN

 

Now you can load FILL2.BIN into Virtual Aquarius as a cartridge ("File | Load Game ROM ..."). I've attached copies of all four of these files in this archive:

 

carttest.zip

[mvdsteenoven]

I am banging my head against the wall here...

Don't do that, you are on roll now!

 

Returning to your previous post; you didn't add an .ORG line in your code.

The .ORG tells the assembler at which memory address the program is loaded.

Since there was no .ORG the assembler assumed that the memory address should $0000.

Recompile the TEST.ASM and check out TEST.LST

LINE   ADDRESS OPCODE           MNEMONICS
0013   0005    CD 11 00    	Call fill		; fill er up

The opcode reads CD 11 00, Call $0011.

So it is actually calling some procedure in Aquarius ROM at address $0011.

 

Jaybird his procedure by creating a ROM cartridge can work for him, but it is only usefull if you want to write complete machinecoded programs. If you want to create a mixture of BASIC and machinecode then it will not work.

 

Let's assume that you have an Aquarius set with a 16K memory extension.

The Aquarius is already using the first 16K of memory (12K ROM, 2K video memory, 256bytes and approx. 1,3K free RAM).

The 16K RAM extension is addressable after the 16K upto 32K in memory.

The highest addressable memory location is 32K - 1, or 32 * 1024 - 1 = 32767

Aquarius reserves the top 50 bytes as a string stack, so your highest available memory is 32717.

Let's take some slack, and use the memory location 32000 as a generic start address for your machinecoded adventures.

 

; File: TEST.ASM
; Displays a few things on the screen.
;
; Use tasm (supplied with VirtualAquarius) to compile:
; tasm -80 -b test.asm
;

     .org  32000        ; You can use decimals as well

main:

     ld   hl, $3400 ; set memory location to color video
     ld   b, $5     ; set register b to color set 55
     Call fill      ; fill er up

     ld   hl, $3400 ; reset memory location to color video
     ld   b, $8     ; set register b to color set 75
     Call fill      ; fill er up
     ret            ; Very good! RET will take you back to BASIC

fill: ld   de,$03ff  ; Use register DE as a byte counter

loop: ld   (hl), b   ; Fill current location in the matrix with character color code
     inc  hl        ; Move to next location in the matrix
     dec  de        ; Decrement byte counter
     ld   a, d      ; Check to see if byte counter has reached zero
     or   e
     jr   nz,loop   ; If byte counter is non-zero, repeat loop

     ret            ; If byte counter is zero, finish loop and return

     .END

Compile it with tasm and use the Obj2DATA.vbs from my previous post to show the DATA lines BASIC:

C:\>cscript //nologo obj2Data.vbs TEST.OBJ
10 DATA 33,0,52,6,5,205,17,125,33,0,52,6,8,205,17,125,201,17,255,3,112
20 DATA 35,27,122,179,32,249,201

Now we write a program in Aquarius BASIC to load the machinecode to memory address 32000 and execute.

30 DATA -1
40 N=32000
50 POKE14341,INT(N/256):POKE14340,N-256*PEEK(14341)
60 READA:IFA=-1GOTO80
70 POKEN,A:N=N+1:GOTO60
80 X=USR(0)

DATA -1 is a marker that will tell us when the machinecode has stopped.

N=32000, again the start memory location for the machine

At line 50 we will tell the USR(0) function where the machinecode can be found.

?PEEK(14340)+(PEEK(14341)*256) will return 32000, the start address for the machinecode.

Some reading and poking to get the machinecode into memory

And the code is executed by X=USR(0)

 

You will probally see only one background color, as the Aquarius is changing colors too quick to see.

 

I hope I haven't spoiled your machinecode puzzle too much by taking you by the hand, but I think there is enough room for more experimenting.

 

Regs

Martin