Aquarius Video Timing

[chjmartin2]

Hi everyone. I have this nagging desire to figure out how to chase the beam on the Aquarius. I just can't shake the thought out of my head. I can't get into any other programming, or even finish my video player. After seeing George Phillip's beamhacking on the TRS-80 Model 3 and knowing that it has a 2.03 MHz Z80 I am convinced that we can chase the beam on the Aquarius.

 

The TRS-80 has the same 2x3 graphics characters set as the Aquarius, so it has the same character based bitmap limitation we work with on the Aq. The major difference for the TRS-80 Model 3 is that the screen is 64x16 with each block being 8x12, so effectively the actual pixel resolution is 512x192 versus the Aq of 320x192 (or 200 for you crazies that want to use the top row.)

 

In concept what you have to do is relatively trivial - just change the characters in the proper timing as the CRT beam draws the screen. If you read the AQ technical documents on the yahoo group, you'll see that it only fetches a 1x8 portion of the character at a time. Martin's page will show you the timing of the NTSC draw.

 

We have 12.8 milliseconds of active scan followed by 2.8 milliseconds of retrace (3.6 for pal, but I don't have a PAL aquarius, so I will work with NTSC timings.) Now, from George's Model 3 pages we have this picture:

 

 

If I had this for the Aquarius I think I would be on a gravy train with biscuit wheels, but I am getting confused by the math.

 

I know the Aquarius has 200 lines in the active scan period, and that it lasts 12.8 milliseconds, which means 64 microseconds per line. (The NTSC standard says 52.6 microseconds in active scan with 10.9 microseconds in HBLANK, or 63.5 microseconds.) Now, an LD r, r' takes 1 microseconds on a 4 MHz Z80. If my math up to this point is correct that would mean that I could complete 64 loads if I hardcoded the data into the program rather than fetching it from memory. That should be more than enough to load 40 character changes per scanline. If I preloaded the colors then I could have an effective resolution (albeit limited by the available graphics characters and lines) of 320x200 with no more than 2 colors per 8x8 block. If I were to change colors by scan line as well, then I would be limited to 32 characters which would be an effective resolution of 256x192 with no more than 2 colors per 1x8 block - again, limited by character combinations.

 

(Random thought: If you think about the timing, then I should easily be able to manipuate a screen of 28x20 blocks for both color and character. 224x160 and even have some cycles left over to update the status at the bottom of the screen. It may be too ambitious, but, since Lode Runner's graphics are 28x18 and appear to be 8x8 pixel blocks, I think I could chase the beam and really be somewhat true to the game.)

 

If you think about the memory requirements, you would need to store a two byte instruction and a one byte character and a two byte instruction and one byte color per line per 1x8 block. If you were to try to max out the screen at 256x192 then that means 32*192*6 = 36,864, which would mean two 16k banks in full 16k bankswitching mode. (ouch, program would have to be replicated and syncronized and pieced together at the byte level - not sure I can do that)

 

If I went for a much more modest approach, then I would have to use an LD r, (hl) which takes 1.75 microseconds. This would limit me to 36 updates per scanline, or a total of 18 characters. I am now at 144x192, which would still put me over the limit on 8k of program code.

 

Ouch - my brain hurts now. I'm not sure that chasing the beam could be used to draw really great pictures, the beam is just so darn fast. I think I would be limited to a very small picture in the middle of the screen... nevermind even programming a game.

 

How did George do it? Also, how do I calculate the above "graph" for the Aquarius?

 

Chris

[GroovyBee]

You don't need to calculate if you have enough time for some experimentation. As a rough idea do the following :-

 

1) Wait until VBLANK occurs in a loop (from what I've read on the Aquarius this is possible).

2) Start another loop that ends when the electron beam is at the top of the screen and the video system is about to start accessing the character RAM.

3) Repeat 8 times :-

3a) Change the 1st character on the scan line.

3b) Execute a sequence of NOPs until the electron beam is on the line below.

4) Goto 1

 

This gives you a ton of flexibility in altering the loop timings to get you going. You might have to throw other instructions in with the MOPs and loops to adjust the cycles taken with as fine a granularity as possible. Just use your best guestimate and then go from there.

 

Once you get the first character lined up and it looks reasonable you can move on to the rest of the screen.

[Aquaman]

Wow, I looked at the TRS pages and If you could pull this off for the Aquarius, it would be another major breakthrough!!!

[chjmartin2]

So here is the problem...

 

The VSYNC goes low and we are in the vertical retrace and then it goes high again and we are in the active scan, but because there is a screen border, I have to get to the point on the screen where it is drawing a character. This is way easier said than done. If I don't bother waiting for the vertical retrace and go ahead and continually load a full character and an empty character I can see lines appear, which tells me that chasing the beam is possible, but, when I wait for the vertical sync bit to go low and then start after it goes high again, I only get a black character, in fact, it never turns off. I can't figure out how many microseconds (therefore T-cycles) that I need to use up between when the vertical retrace is over and the character drawing begins, and I have no idea how many scanlines it is... arggggggg......

 

What really is frustrating is that I only have 8 1 meg eproms and my Supercart is configured for 1 meg roms, if I had it configured for 64k then I can use my EEPROMS, but I am afraid to reconfigure my Supercart because last time I did that I fried one... So I only have 8 shots at programming and then I have to erase, so I get 4 at a time.

 

This is so hard without a cycle-accurate emulator.

 

I want to chuck this thing out the window.

 

If the total screen size is 240 lines then I would think that 20 are on the top and 20 are on the bottom, this means 64 microseconds * 20 lines = 1,280 microseconds and that means 320 NOPs just to get to the first line? Can't be, can it???

 

NTSC says that total screen size is 525 lines, but 480 visible, and I know that I have 200 lines in the drawing area. 480x2 is 240, so it has to be using two TV lines for one Aquarius line.

 

I'm guessing it is progressive scan, but would it even work like that?

 

See my issues?

 

I hate beam chasing - because if it isn't progressive scan, then that means there would be two VSYNCs per screen draw, and then what would I do?

 

But it doesn't look like that, when I rapidly cycle - I only get what looks like 8 lines...

 

ARRRRRG!

[jaybird3rd]

What really is frustrating is that I only have 8 1 meg eproms and my Supercart is configured for 1 meg roms, if I had it configured for 64k then I can use my EEPROMS, but I am afraid to reconfigure my Supercart because last time I did that I fried one... So I only have 8 shots at programming and then I have to erase, so I get 4 at a time.

 

This is so hard without a cycle-accurate emulator.

Reconfiguring the SuperCart board for 64K is easy: just clear the solder from jumpers W6, W7, W8, and W9 (on the back of the board), and then change jumper W1 (near the EPROM, at the top of the board) from position 2-3 to position 1-2. Refer to the silkscreened outline in the EPROM footprint for plugging in a 28-pin device like your 64K EEPROMs. Either that, or I can put together a new SuperCart preconfigured for 64K for you.

 

I too would love to see a cycle-accurate Aquarius emulator. Virtual Aquarius, probably the most highly-developed of the Aquarius emulators to date, seems to have been designed for BASIC programmers and for the existing library of Aquarius software, so it has its limitations. The Aquarius driver in MESS has a good debugger (which Virtual Aquarius lacks), but it doesn't seem to support expanded RAM or the hand controllers, so its usefulness is also limited. I'd be happy if we got an emulator which supports the SuperCart bankswitching modes.

 

Whatever the outcome, thanks for your work with this. I'm hoping that my SuperFont upgrade idea will provide a much easier way of breaking beyond the limitations of the Aquarius character set, but I can also see these beam-racing techniques being potentially useful for multi-colored Aquarius characters, and possibly even changing the colors every scanline within a character cell.

[chjmartin2]

Hi All,

 

Well... some small progress. I am fairly certain that there are 256 T-States per scan line, which implies a real resolution of 384 horizontal dots, so 64 dots during the Horizontal blanking period.

 

I used that to try to calculate the full screen timing, here is my current best guess:

 

 

Anyway, I decided to go ahead and get as close as I could. It is frustrating because I only have 4 roms before I have to pull out the UV eraser. (New cart from Jay on the way that will speed up the testing.) Anyway, here is a still shot of the screen, there is some flickering on the first 8 dots on the upper right, along with some flickering on line 6, dots 16-48 - but the first 5 lines are perfect with no flicker!

 

 

This shows that it can be done and that the method the PLA-2 puts together the video signal (one 1x8 block at a time) doesn't negate the method. I still have a boatload to figure out, but thought you'd all appreciate the update. Make sure you click on it to see it up close, it has some very clear lines.

 

Thanks,

 

Chris

 

(P.S. Jay - if you want to move this to the programming forum, I posted it here by mistake.)

[GroovyBee]

I'm glad to see that you are making progress on this.

[Aquaman]

Nice job!!!

[Richard Chandler]

I've now added tstate accurate display updating to my Aquarius emulator AquaLite. Whilst writing the code I've investigated and discovered the timings for a complete frame write and display.

 

There are 228 tstates per line, this is made up of the following.

 

Left Border       Display Area       Right Border    Horizontal Sync

   8 tstates         160 tstates            8 tstates        52 tstates             = 228 tstates.

 

This means there are 16 pixels for left border, 320 pixels for display area and 16 pixels for right border.

 

There are 312 lines for PAL version and 262 for NTSC version. This is made up of:

 

Top Border - 16 lines

 

Display Area - 200 lines

 

Bottom Border - 16 lines

 

Vertical Sync - 80 lines (PAL) / 30 lines (NTSC)

 

This means there are 71136 tstates (PAL) or 59736 tstates (NTSC) per frame.

 

I'll post again when AquaLite is ready for release, I've already vastly improved the AY sound output and improved keyboard reading.

[jltursan]

Really interesting info, pretty close to the results obtained with a ZX Spectrum 128K/+2

 

So the classic info about the Aquarius timings is a little outdated:

 

    |<-    Active scan period   ->|V.sync |<-

    |      12.8 mS                |3.6 for PAL

    |                             |2.8 for NTSC

    +++++++++++++++++++++++++++++++       ++++++++++++

    +                             +       +

    +                             +       +

+++++                             +++++++++

 

For a NTSC machine, given its 4 MHz clock it results: (2,8ms * 4000000) / 1000ms = 11200 tstates

 

Following your numbers and given that the vsync starts right after the last visible line and thus it must cover the entire bottom border + vertical sync + top border = 64 lines * 228T = 14592 tstates

 

I'm not really 100% sure about my math but I best prefer your results indeed, they give about 25% more process time in the vsync period ?

 

[chjmartin2]

On 1/10/2021 at 6:16 PM, Richard Chandler said:

I've now added tstate accurate display updating to my Aquarius emulator AquaLite. Whilst writing the code I've investigated and discovered the timings for a complete frame write and display.

 

There are 228 tstates per line, this is made up of the following.

 

Left Border       Display Area       Right Border    Horizontal Sync

   8 tstates         160 tstates            8 tstates        52 tstates             = 228 tstates.

 

This means there are 16 pixels for left border, 320 pixels for display area and 16 pixels for right border.

 

There are 312 lines for PAL version and 262 for NTSC version. This is made up of:

 

Top Border - 16 lines

 

Display Area - 200 lines

 

Bottom Border - 16 lines

 

Vertical Sync - 80 lines (PAL) / 30 lines (NTSC)

 

This means there are 71136 tstates (PAL) or 59736 tstates (NTSC) per frame.

 

I'll post again when AquaLite is ready for release, I've already vastly improved the AY sound output and improved keyboard reading.

So, your emulator is cycle accurate meaning we could use it for proper dev?   I left so much not done when I put away my Aquarius and one of those things was chasing the beam, I'd love to revisit that work... can't find your emulator though!

 

[Richard Chandler]

Having done further investigation I reckon it might actually be 229.5 tstates per line. I don't have a real machine to be able check properly.

 

And yes, it is cycle (tstate) accurate as has been proven by the fact that AquaLite is the only emulator able to run Mack Whartons Xmas demo correctly.