[AQUARIUS] Machine Language Programming on the Aquarius

[jaybird3rd]

Am I the only one that still doesn't own a non-"S2" model?!

There's probably no good way to find out, but I'd love to know how many of the surviving Aquarius computers are the older models and how many are "S2" models. I'd imagine that the majority are "S2" machines, especially if you don't own any of the older ones yourself. What's funny is that, of the two that I own, one of them came in a "Family Pack" closeout package, so there must have been enough of the older models made that Mattel still had some left over when the Aquarius was discontinued.

 

@Jay,

The non-"S2" ROM is still not available for the Virtual Aquarius. Could you please dump it and upload it?

Ah, I didn't realize that version of the ROM was missing. It might be a week or two before I have time to crack my machines open, but I'd be glad to dump it. I'll post it to the Yahoo! newsgroup also.

[+MattelAquarius]

Since the Aquarius wasn't marketed outside the US until the Radofin era, and because all Radofin era machines are S2 units, I think the odds were against Martin getting a non-S2 machine.

 

Then again, judging by the database, I would've guessed Martin did have a non-S2 unit. Strange.

 

Too bad not everyone reported their S2 status on the database.

[jaybird3rd]

Since the Aquarius wasn't marketed outside the US until the Radofin era, and because all Radofin era machines are S2 units, I think the odds were against Martin getting a non-S2 machine.

You're right, I hadn't considered that.

 

Then again, judging by the database, I would've guessed Martin did have a non-S2 unit. Strange.

 

Too bad not everyone reported their S2 status on the database.

Yeah, I'm afraid I forgot to enter the hardware revision with the serial numbers I put in, too. It wasn't a required field, so unless the owners specifically remembered to include that information, it wasn't recorded. It's not too important, I suppose, but it would have been nice to know.

[chjmartin2]

I want to move on to the next thing, but I can't leave this unsolved. What do I do next?!

 

Hi Chris,

You have travelled way beyond anyone has ever gone with the Aquarius.

But have you tried switching the wait sequence? Like first wait for VSYNC to get low, and then wait for high.

How about the suggestion on Yahoo groups; create your own loop instead of using LDIR (because of the undocumented waitstate to clear the registers, although I do believe that I have read somewhere that a common LD also needs a moment to clear the registers - but I could be mistaken)

Perhaps you could try only upper half of the screen instead of the full screen, in case the emulator works faster then the real Aquarius.

 

Regs,

Martin

 

 

Martin,

 

Thanks for the encouragement. I have changed the wait sequence, Low then High - High then Low - Low, High, Low - High, Low, High ... So far, I get my best result in just waiting for the VSYNC to go low and loading my data. If I understand this correctly, and maybe this will help. The first bit on port 253 is normally high - that is, it is equal to 1 when the beam is active and then it goes low during the time the beam is not active. The program that gets me the closest just starts loading data when the sync is low, but what is strange, is that it is the top of the screen that is corrupted. Now, if I start drawing when the VSYNC is low, for all the cycles it is low, I beat the beam down the screen... OMG OMG OMG... While I was typing!!!!!

 

WAIT! I know what is happening. The screen draw takes too long, so I am missing the VSYNC for frame two. Hear me out. Wait for VSYNC to go low, load characters, then load colors. I have no idea how many cycles that is, but it is 1,920 bytes being loaded from cartridge ROM to video RAM. I bet that I am running out of time by the time I get to the bottom. If the VSYNC goes low during my update then I would miss it and have to wait for it again before I started the next screen. Even worse, I draw the characters and then the color - I don't wait in between for the VSYNC.

 

How do I count cycles in my machine language program? I can verify that this is happening, by just trying to load the bottom half (or top half) of the screen. Because I am using LDIR - I can't check in on the VSYNC during the loading. Another way to test is to try to just load characters and not colors or vice-versa. This has to be what is happening.

 

The weird part is, that when it is not working, it is still showing two frames, with no break in the middle, but the wrong character/colors. I have tried writing my own loader not using LDIR, and the result was worse, it ran much slower on the emulator and on the real thing. Made it flicker a lot more because it took way too long to load, compared to LDIR.

 

Tonight I will modify a program to start loading 1/4 down the screen and stop at 3/4 of the screen to try to load 75% and see what I get. I bet that fixes it. I'd really love to count the cycles - how do I find out how many cycles per operation?

[chjmartin2]

Since the Aquarius wasn't marketed outside the US until the Radofin era, and because all Radofin era machines are S2 units, I think the odds were against Martin getting a non-S2 machine.

 

Then again, judging by the database, I would've guessed Martin did have a non-S2 unit. Strange.

 

Too bad not everyone reported their S2 status on the database.

 

Most days I feel like there are only 3 of us who even LIKE the Aquarius! ha

[mvdsteenoven]

Now, if I start drawing when the VSYNC is low, for all the cycles it is low, I beat the beam down the screen... OMG OMG OMG... While I was typing!!!!!

Cool... Live action!

 

How do I count cycles in my machine language program?

I never had to count the cycles, but there is an PDF Manual on the Zilog website that tells about timing, T-States and M-Cycles.

 

LDIR Command

For BC ≠ 0:
  M Cycles      T States         4 MHz E.T.
     5      21 (4, 4, 3, 5, 5)      5.25

For BC = 0:
  M Cycles      T States         4 MHz E.T.
     4      16 (4, 4, 3, 5)         4.00

 

I believe I have read somewhere about a register reset which takes some additional cycles as well, but I can't remember where I read this.

Also Ian Gledhill on the Yahoo Group said in message 1532 that the Z80 isn't fast enough and it can only process 10 blocks if you want to keep up with the beam.

 

Regs,

Martin

[chjmartin2]

Now, if I start drawing when the VSYNC is low, for all the cycles it is low, I beat the beam down the screen... OMG OMG OMG... While I was typing!!!!!

Cool... Live action!

 

How do I count cycles in my machine language program?

I never had to count the cycles, but there is an PDF Manual on the Zilog website that tells about timing, T-States and M-Cycles.

 

LDIR Command

For BC ≠ 0:
  M Cycles      T States         4 MHz E.T.
     5      21 (4, 4, 3, 5, 5)      5.25

For BC = 0:
  M Cycles      T States         4 MHz E.T.
     4      16 (4, 4, 3, 5)         4.00

 

I believe I have read somewhere about a register reset which takes some additional cycles as well, but I can't remember where I read this.

Also Ian Gledhill on the Yahoo Group said in message 1532 that the Z80 isn't fast enough and it can only process 10 blocks if you want to keep up with the beam.

 

Regs,

Martin

 

That's a good point, but he was doing 10 blocks per line to keep up with the beam as it went from line to line. I am not chasing the beam down the screen. If I start my update when the VBLANK period first starts, then I have until the end of the VBLANK and all of the Active Scan period.

 

So, process goes like this.

 

1. Wait for VSYNC to go low

2. Move Characters from Cart Rom to Video RAM

3. Move Colors from Cart Rom to Video RAM

4. Wait for VSYNC to go low again

 

Now, if the screen update were faster than the VBLANK period, then I might try to switch the screen too fast, and that is what I thought I was running into before. Then James gave me a fix where you wait for the VSYNC bit to go low, then wait for it to go high, then draw the data. This worked great in the emulator, but no so well on the real thing.

 

Either one of two things is true. I am updating the screen too fast and when I go to update the video ram I am updating it before it has had a chance to get displayed, OR, I am updating the screen too slow and I am updating past the NEXT VSYNC. I will test this by trying to only update half of the screen.

[chjmartin2]

Martin,

 

Can you tell me where you got your technical reference on the VSYNC bit for the Aquarius? I haven't seen it referenced elsewhere. I really am stuck on timing the screen redraw. I have tried to just load 1/2 the screen and it doesn't fix the problem. Also, I have found weird behavior, that the bad screen draw is not the first frame that I try to load, but rather, the other of the code that loads the frame. You aren't confused - you read that right. If I change my code to call the second frame load first, it is still the first frame that draws bad. If I go ahead and swap the code, put the frame 2 loader first and the frame 1 loader second, then the second frame is the bad draw, regardless of when I call the subroutine.

 

The aquarius result is odd as well, because at the point where the image goes from bad to good, there is a line that looks like 1/4 of a character that is flip flopped, it is like 4 characters taking up one space, but only the top quarter of 2 and the bottom 3 quarters of another 2.

 

Needless to say, I have tried to start my load when the bit is high and start my load when the bit is low. I have tried to create an init routine that loops if it is zero, then loops if it is one, then loops if it is zero again. This makes sure that the program DEFINATELY starts with the bit high, and definately at the moment when it goes high - same for the opposite. I have tried to write a pause routine, but the calls to it make it way too slow. I'd love to be able to "see" the value of bit 0. I feel like I am missing something simple.

 

Chris

[chjmartin2]

Ok, so I need some thinking help. So I have a data stream that looks like this:

 

10011100 01101010 10101010 11101100 11111111 10000111

 

Now, each set of three bits represents a value and I want to isolate those values.

 

My first thought was load the byte into a register, let's say e and then and it with 11100000, 00011100 and then 00000011.

 

The problem is, how do I load the next byte in order to get the last bit. I can't store the data in full bytes because I'd run out of room.

 

Also, I have to figure out how to make the timing work the same between each 3 bit value, so I can't have exotic code in between byte values, or I'd have to add a delay to the easy ones.

 

Any ideas?

[catsfolly]

Ok, so I need some thinking help. So I have a data stream that looks like this:

 

10011100 01101010 10101010 11101100 11111111 10000111

 

Now, each set of three bits represents a value and I want to isolate those values.

 

My first thought was load the byte into a register, let's say e and then and it with 11100000, 00011100 and then 00000011.

 

The problem is, how do I load the next byte in order to get the last bit. I can't store the data in full bytes because I'd run out of room.

 

Also, I have to figure out how to make the timing work the same between each 3 bit value, so I can't have exotic code in between byte values, or I'd have to add a delay to the easy ones.

 

Any ideas?

 

One way would be to do something like this:

 

 
; value 1 contains  xxxxxx11
       ; value 2 contains  2xxxxxxx
; result is     xxxxx112
    
ld	a,(value1)      ; get the value with 2 bits in it
ld	e,(value2)      ; get the number with the next bit in the highest bit
rlc	e		; rotate e left, copy the highest bit to the carry bit
rla			; rotate a left, copy the carry bit to the lowest bit 

 

The "rla" instruction only works on the "a" register, so you have to use it there.

 

If you have one bit in the first value, and 2 bits in the second value:

 

       

        ; value 1 contains  xxxxxxx1
        ; value 2 contains  22xxxxxx
 ; result is     xxxxx122

       ld	a,(value1)      ; get xxxxxxx1
ld	e,(value2)      ; get 22xxxxxx
rlc	e		; rotate e left, copy the highest bit to the carry bit
rla			; rotate a left, copy the carry bit to the lowest bit
rlc	e		; rotate e left, copy the highest bit to the carry bit
rla			; rotate a left, copy the carry bit to the lowest bit

 

Does this make sense?

 

David

[chjmartin2]

Ok, so I need some thinking help. So I have a data stream that looks like this:

 

10011100 01101010 10101010 11101100 11111111 10000111

 

Now, each set of three bits represents a value and I want to isolate those values.

 

My first thought was load the byte into a register, let's say e and then and it with 11100000, 00011100 and then 00000011.

 

The problem is, how do I load the next byte in order to get the last bit. I can't store the data in full bytes because I'd run out of room.

 

Also, I have to figure out how to make the timing work the same between each 3 bit value, so I can't have exotic code in between byte values, or I'd have to add a delay to the easy ones.

 

Any ideas?

 

One way would be to do something like this:

 

 
; value 1 contains  xxxxxx11
       ; value 2 contains  2xxxxxxx
; result is     xxxxx112
    
ld	a,(value1)      ; get the value with 2 bits in it
ld	e,(value2)      ; get the number with the next bit in the highest bit
rlc	e		; rotate e left, copy the highest bit to the carry bit
rla			; rotate a left, copy the carry bit to the lowest bit 

 

The "rla" instruction only works on the "a" register, so you have to use it there.

 

If you have one bit in the first value, and 2 bits in the second value:

 

       

        ; value 1 contains  xxxxxxx1
        ; value 2 contains  22xxxxxx
 ; result is     xxxxx122

       ld	a,(value1)      ; get xxxxxxx1
ld	e,(value2)      ; get 22xxxxxx
rlc	e		; rotate e left, copy the highest bit to the carry bit
rla			; rotate a left, copy the carry bit to the lowest bit
rlc	e		; rotate e left, copy the highest bit to the carry bit
rla			; rotate a left, copy the carry bit to the lowest bit

 

Does this make sense?

 

David

 

Looks great... I will try it tonight. I have to figure out the repeat though.

[chjmartin2]

So I can't figure out why this just shows garbage. I realize that the timing will be terrible because each sample extraction has a different set of instructions. My plan is to add some kind of delay to each extraction to get the timing right, but this doesn't even run, it assembles without error, but then throws up garbage on the emulator - no sound output at all. Can you look at my code and see if you can spot a mistake? I hate that I always have to come online for help. Thank you in advance.

 

 

; Program to Play 2 Bit PCM file at 4.2kHz using Pulse Width Modulation on the Aqaurius Sound Port

.org $E000			

.db $b6, $b7, $24, $2a, $8d, $9c, $42, $b0
.db $53, $6c, $90, $64, $89, $a8, $f9, $70

MAIN:
ld hl, SAMPLE		; Memory Location to ROM Sample
ld bc, 4000		; Number of Samples	

replay:	
ld e, (hl)			; load an 8 bit set	
ld a, 192			; load up my 'and' tester (192 = 11000000)
and e			; now my accumulator has my sample
rlca			; rotate left
rlca			; rotate left
ld e, a			; send accumulator into e
call subsamp		; play the sample	

ld e, (hl)			; reload the 8 bit set
ld a, 48			; load up my 'and' tester (48 = 00110000)
and e			; now my accumulator has my sample
rlca 			; rotate left
rlca			; rotate left
rlca			; rotate left
rlca			; rotate left
ld e, a			; send accumulator into e
call subsamp		; play the sample

ld e, (hl)			; reload the 8 bit set
ld a, 12			; load up my 'and' tester (12 = 00001100)
and e			; now my accumulator has my sample
rrca 			; rotate right
rrca			; rotate right
ld e, a			; send accumulator into e
call subsamp		; play the sample

ld e, (hl)			; reload the 8 bit set
ld a, 3			; load up my 'and' tester (3 = 00000011)
and e			; now my accumulator has my sample
ld e, a			; send accumulator into e
call subsamp		; play the sample

inc hl			; Move to next Sample
dec bc			; Decrement Sample Counter
ld a, c			; Load C 
or b			; Is BC Zero
jp nz, replay		; If it isn't zero, keep playing

subsamp:	
ld d, 4			; 8 Cycles per Sample
highcycle:	
ld a,0			; Give me the Low Bit
out ($fc),a			; Send the Low Bit
dec d			; Drop the Cycle Counter
dec e			; Drop the High Cycle Counter
ld a,e			; grab e
jp nz, highcycle		; Send 1's Until we are done
lowcycle:
ld a,1			; Gimme a One
out ($fc),a			; Send Out the High Bit
dec d			; Drop D again
ld a, d			; Check on D
jp nz, lowcycle

RET

[mvdsteenoven]

So I can't figure out why this just shows garbage. I realize that the timing will be terrible because each sample extraction has a different set of instructions. My plan is to add some kind of delay to each extraction to get the timing right, but this doesn't even run, it assembles without error, but then throws up garbage on the emulator - no sound output at all. Can you look at my code and see if you can spot a mistake? I hate that I always have to come online for help. Thank you in advance.

 

subsamp:	
ld d, 4			; 8 Cycles per Sample
highcycle:	
ld a,0			; Give me the Low Bit
out ($fc),a			; Send the Low Bit
dec d			; Drop the Cycle Counter
dec e			; Drop the High Cycle Counter
ld a,e			; grab e
jp nz, highcycle		; Send 1's Until we are done
lowcycle:
ld a,1			; Gimme a One
out ($fc),a			; Send Out the High Bit
dec d			; Drop D again
ld a, d			; Check on D
jp nz, lowcycle

RET

 

Hi Chris,

I am not sure what you are trying, but on the "highcylce" you are sending 0 (Give me the Low Bit) to port $fc, while on the "lowcycle" you send 1 (Gimme a One).

You are changing bit 0 on the I/O port, while you should be changing bit 7.

Try sending $FE (254) for the low bit, and send $FF (255) for the high bit.

 

I can't see anything in the code that would explain why you get garbage on your screen.

But I do see that you do not HALT or loop after all sounds have played.

When all samples haved played and BC hits zero the program continues into the subsamp procedure, without anywhere to RETURN. That might jump anywhere.

Just put a HALT, or endless loop, just before the procedure subsamp and see if this will stop the garbage.

 

Regs

Martin

[+DZ-Jay]

WAIT! I know what is happening. The screen draw takes too long, so I am missing the VSYNC for frame two. Hear me out. Wait for VSYNC to go low, load characters, then load colors. I have no idea how many cycles that is, but it is 1,920 bytes being loaded from cartridge ROM to video RAM. I bet that I am running out of time by the time I get to the bottom. If the VSYNC goes low during my update then I would miss it and have to wait for it again before I started the next screen. Even worse, I draw the characters and then the color - I don't wait in between for the VSYNC.

 

Hey guys,

 

I don't know anything regarding the Aquarius Computer, but I noticed that the pattern you are describing is similar to a phenomenon that occurs in the Intellivision. I imagine that the Aquarius follows close to the same hardware design as the Gimini (from where the Intellivision was based), so I thought this may be relevant. Please forgive me if it is not.

 

It definitely sounds like you are running out of time. In the Intellivision, when VBLANK hits, the CPU asserts control of the data bus away from the STIC (i.e., the "video chip"), but it only does so for a couple of thousands cycles. The Aquarius may follow a similar design with a shared bus, and thus limit the time you have to access graphics RAM.

 

There are two periods in the Intellivision that my occur in the Aquarius, which you may have to consider: first is when the CPU has access to the video chip itself (Period 1); and second, when the CPU has access to graphics RAM (Period 2). Period 2 overlaps Period 1; the latter lasts for about 2,900 cycles, while the former lasts for a full 3,796 cycles--again, these are Intellivision timing periods.

 

If this explains what you're seeing in your tests, then it may offer some insight. It also reveals that the emulator you are using is not very accurate if it can't reproduce the hardware timing correctly.

 

-dZ.

Edited May 22, 2011 by DZ-Jay

[mvdsteenoven]

I am using dZ80w v2.0 for disassembling Aquarius programs.

You can find the original website here: http://www.inkland.org.uk/dz80/

The executables for Windows have been attached:

 

dz80w200.zip

 

dZ80w has been created to disassemble ZX Spectrum binaries, but you can also add your own scripts that will be executed during disassembly. These scripts must be written in the LUA 4.0 script language. More about the LUA script language here: http://www.lua.org and http://lua-users.org/wiki/

 

Here you can find my Aquarius script for dZ80w:

 

Aquarius_lua.zip

 

It will add comments when standard Aquarius memory addresses are being used, and whenever there is a CALL to a standard Aquarius subroutine in ROM.

It also handles RST 08 and RST 30 correctly.

 

How does it work:

 

First you must unscramble the Aquarius ROM that you want to disassemble.

You can find a post with an Excel sheet that contains the known scramble codes for the ROMS here

The Aquarius cart is scrambled using one XOR byte.

 

Next start dZ80w and click the button options. Within Disassembly control set the following options:

 

Start: 49152 End: 65535

File Start: 49152 File hdr: 0

 

(49152 equals C000 hexadecimal, the Aquarius memory address where a 16K cart is loaded)

 

At the “Files to use” you can add the Aquarius.lua script.

 

 

Press OK to confirm the options and return to the opening screen.

 

Now you can press the button [ Browse ] to locate your unscrambled Aquarius cart binary and start to disassemble it.

 

 

Enjoy!

 

Regs,

Martin

Edited August 6, 2011 by mvdsteenoven

[jaybird3rd]

Thanks VERY much for posting this, Martin! With the dZ80w disassembler and script, and the descramble codes for the original cartridges, Aquarius programmers now have everything they'll need to analyze the original games and applications.

[nitrofurano]

It occurs to me that I should also post some tools that Aquarius programmers would find helpful. The first is the Virtual Aquarius emulator: it's a few years old and is Windows-only, but it's still the best and most fully-featured emulator for the Aquarius, and I'm told that it runs well under Linux and other platforms using Wine. This is version 0.72, which I believe is the most recent version. It also includes a number of cartridge and cassette images to get you started:

 

well, i don't know if it is only on Wine, but QuickType doesn't work fine there, like not recognizing characters like '=' and so on - that's why i'm looking for a tokenizer to .caq files, do someone know where can we get from, or where is documentation enough to start coding one?

[+Gemintronic]

Thanks VERY much for posting this, Martin! With the dZ80w disassembler and script, and the descramble codes for the original cartridges, Aquarius programmers now have everything they'll need to analyze the original games and applications.

 

Does this mean homebrew Aquarius ROMs must be encrypted?

[jaybird3rd]

Does this mean homebrew Aquarius ROMs must be encrypted?

Not encrypted, thankfully; they just need a 16-byte header at the location where the Aquarius begins executing the code. The Aquarius checks this header first, and if it is valid, it proceeds to execute the program in the cartridge instead of BASIC. Martin's generator makes it very easy to create valid headers, and in either this thread or the SuperCart I thread, I posted some "official" SuperCart I headers which I made using Martin's tools.

 

As it turns out, there's a much simpler way of using them than the method I described at the beginning of this thread. Just include a few lines like these at the beginning of your assembler file, and you should be all set:

 

 .org $E000

 ; Aquarius Cartridge Header (SuperCart I, 8K Mode)

 .db $53, $43, $30, $38, $4B, $9C, $B5, $B0, $A8, $6C, $AC, $64, $CC, $A8, $06, $70

 ; (The rest of your code begins here)

 

This will embed the header data directly in the right place in the binary. I used my 8K header here, but any valid header will do.

[mvdsteenoven]

Not really Machine Language Programming, but as this thread also contains Aquarius Programmer Tools I found this the best option.

 

Theloon has made a suggestion for an Aquarius bootstrap to load BASIC files from cartridge. As I thought it should be possible I have created the following solution.

 

In the attached ZIP file you will find the following files:

* BOOTLDR.DAT - The cartridge boot procedure

* Caq2Bootload.vbs - Visual Basic Script whichs concatenates your CAQ file to the BOOTLDR.DAT (plus minor modifications to the .CAQ)

* Bootloader.asm - The Z80 assembly used to created BOOTLDR.DAT

* bomber_bas.caq - A pure BASIC game by DigitalOutput distributed with the Virtual Aquarius

* bomber_bas.bin - Cartridge version of the BASIC game

* README.TXT - This text

 

First, create your Aquarius BASIC program and save it, using the Virtual Aquarius, as a CAQ file.

Place the files BOOTLDR.DAT and Caq2Bootload.vbs in the same folder (e.g. your desktop)

Drag your CAQ file over Caq2Bootload.vbs and drop it.

A file with the extension .BIN will be created in the same folder as the .CAQ file

 

Or by command prompt:

C> cscript Caq2Bootload.vbs bomber_bas.caq

 

Load the cartridge in your Virtual Aquarius.

Once the bootloader is active it will no longer go to the immediate mode, you will not be able give any BASIC commands.

If you press CTRL+C or if an error occurs the BASIC program will restart (RUN)

 

Please note:

The CAQ file and the BOOTLDR.DAT should not exceed 8K

This is the first version of the bootloader and it may contains flaws.

Any comments are welcome.

 

bootldr-1.zip

 

Enjoy!

 

Regs,

Martin

[+Gemintronic]

Wow wow WOW!!! This means new Aquarius homebrew is possible even for luddites like me!!! THANKS mvdsteenoven! =)

 

@jaybird3rd: What would you need to produce carts? Just the binary created by this utility and perhaps cart shells?

[jaybird3rd]

Thank you, Martin! I haven't had the chance to try this yet, but it should indeed make it much easier for aspiring Aquarius programmers to get started.

 

@jaybird3rd: What would you need to produce carts? Just the binary created by this utility and perhaps cart shells?

I'll know for sure once I try it myself, but yes, if Martin's tool produces valid cartridge binaries, all I should have to do is burn the binary to a ROM and assemble the cartridge. Being limited to 8K, the binaries won't use the full capacity of the cartridge, but the cartridges themselves should be very easy to make.

 

I'm glad this became available before I've finalized my revised cartridge board design. I'll try to work in a few changes to make it cheaper to assemble cartridges for the binaries produced by this tool. Assuming everything works as I think it will, I'll be able to offer inexpensive cartridge assembly as a service for Aquarius homebrewers.

[mvdsteenoven]

Please note:

The CAQ file and the BOOTLDR.DAT should not exceed 8K

 

Just noticed that I forgot to put in a check in the Caq2Bootload.vbs when the file exceeds 8K.

I'll put it on my todo list

The Aquarius will just not recognize the ROM if it is bigger then 8K

If you plan to create a physical cart then you should wire the ROM to use address 0xE000 - 0xFFFF

 

Regs,

Martin

[barnieg]

Now I need a really need a real Aquarius & expander!

[Aquaman]

This is really great stuff Martin!!! I could easily think that you could also make a basic compiler for us not so great Assembler programmers