Tempest is possible

[CunningFellow]

Does the HEX file in the "Default" Directory of the file "TempestTestCode.zip" on the 3rd page of this thread work on real hardware ?

That would let me know if it is the TIMER1_OVF being a problem or if it is my massively unrolled case statement for the 512 different pixel combinations.

[D3thAdd3r]

I will test it. I don't have a build environment setup on my new computer and looks like there isn't a pre-compiled version of the new uzem(just avr8.cpp looks updated). Mind sending it my way so I can make sure my .uze is even good before I steer you wrong



Edit - yes the vectordemo.uze in there works on real hardware

[CunningFellow]

Thanks D3athadd3r,

That means it is probably my 512 IJMPS causing the problem. That colour stripe picture you just got uses Timer1-OVF to end the render_line routine. It also has the alternate reset interrupt happening.

I wonder if I am crashing into the bootloader in memory or something. Well - I have tonight off so I can spend some time building some real hardware hopefully.

[CunningFellow]

I've just had a thought.

Is the bootloader a menu driven thing? If so it probably sets PORTC to an output before it calls user code ? That will not work with my code.

At the reset vector I test to see if port C is an input and jump to __INIT if it is. If PORTC is already an output then I jump to the pixel render code for

Yellow-Yellow-Yellow-Yellow

To work with my code the BOOTLOADER will have to set PORTC back to in input (DDRC=0x00) before calling the USER_CODE.

This is my code at memory location 0x0000

Code: Select all

RenderLines:
     out    _SFR_IO_ADDR(PORTC), r23        ; RESET VECTOR
     sbis   _SFR_IO_ADDR(DDRC),1            ; If DDRC is set as input
     jmp   __init                           ; jump to __INIT

     nop                                    ; Otherwise do pixel code
     out    _SFR_IO_ADDR(PORTC), r23
     rjmp .
     ld     YL, X+
     out    _SFR_IO_ADDR(PORTC), r23
     ld     ZH, Y+
     mov    ZL, ZH
     andi   ZH, 0x0F

I really am seriously bending the rules to get this video mode to work.

[D3thAdd3r]

I think you are on to it. If I set boot: game so that it's supposed to boot to the last loaded game, and then reset, it doesn't work with RenderTest.uze, but with your previous version it works like normal. Basically it doesn't sync when you hit reset the bootloader acts like there was no game flashed

[CunningFellow]

Ah - good - that does not sound like a show stopper. Just needs slight change to the bootloader code.

I will still try make my own hardware tonight so I don't have to keep asking people to test things for me.

I will still post up progress reports and code, I just should know they work before hand

[CunningFellow]

I checked the source tree and could not see any other usage of GPIOR registers. So I changed my logic from looking to see if PORTC was an output to actually having a FLAG set in GPIOR0.

When the video mode gets initialized I do this.

Code: Select all

InitializeVideoMode:
     sbi     _SFR_IO_ADDR(GPIOR0), 0

And I changed the reset code to this.

Code: Select all

RenderLines:
     out    _SFR_IO_ADDR(PORTC), r23	     ; RESET VECTOR (output first yellow pixel)
     sbis   _SFR_IO_ADDR(GPIOR0),0      ; If flag is not set
     jmp   __init                                   ; jump to __INIT

Hopefully that has made it bootloader compatible and this is what you should see

web.png (3.49 KiB) Viewed 8411 times

[Karl_A]

Yes, the last file works on real hardware

[CunningFellow]

Thank you very much Karl and D3athAdd3r,

That has 100% answered the questions.

We know the issue was the bootloader leaving PORTC as an output.

More importantly my 2.1bpp (5 colour) mode works on real hardware.

I am about 1/3 way through re-drawing the schematic in gEDA. So not much hope of me finishing the PCB tonight. I am very rusty from 5 years of not working with electronics

[D3thAdd3r]

Good deal, you're moving forward fast. Out of curiosity what kind of flash budget do you suspect you'll have for sound? I wish Uzebox could just load sound events for the songs off SD, keeping patches in flash. Then there would be no such thing as worrying about 12k worth of songs like I always have to have in my games