Go Down

Topic: Arduino/ATmega328 C64 Emulator (Read 31781 times) previous topic - next topic

janost

#30
Nov 06, 2013, 11:47 pm Last Edit: Nov 07, 2013, 01:19 am by janost Reason: 1
It also made the 2 columns before column 0 White, e.g 0xFFFF.
Stlll have 40 columns but 2 White ones before the 40 characters are shifted.
 
Code: [Select]

  const register byte * linePtr = &charROM [ row & 0x07 ] [0];
   register byte * messagePtr = (byte *) & videomem [videoptr] ;
   
   c=40;
   while ((UCSR0A & _BV (UDRE0)) == 0)
     {}
   //UCSR0B =0;  
   UCSR0B = _BV(TXEN0);
   while (c--){
    UDR0 = pgm_read_byte (linePtr + (* messagePtr++));  
   }



nickgammon

Please post technical questions on the forum, not by personal message. Thanks!

More info: http://www.gammon.com.au/electronics

janost


janost

What could make it miss 2 loads before the new shiftload code?
It wasnt there before.

nickgammon



Are you sleeping?


Yes, i was.
I live in Sweden so it got late :)


Not you.

Quote

But something else happened with the Vsync that needs to be resolved as its not steady anymore.


The processor. Do you make it sleep between Vsync pulses?
Please post technical questions on the forum, not by personal message. Thanks!

More info: http://www.gammon.com.au/electronics

janost


But something else happened with the Vsync that needs to be resolved as its not steady anymore.


The processor. Do you make it sleep between Vsync pulses?
[/quote]

Yes, but I have it commented out at the moment as it makes no difference with an empty Loop() function.
The Vsync is ok now, it was another mistake.

Still it misses 2 loads before the pixelblast. 

janost

#36
Nov 07, 2013, 10:56 am Last Edit: Nov 07, 2013, 11:25 am by janost Reason: 1
I don't think assembler is messy. But the way you write it inline is.
It does exactly what you tell it to do and there is no compiler mucking things up.

To get this stable I think the whole videoline needs to be written in assembler, from sync to the last pixel.
That way you know it's rockstable.

I think that the compiler did something with the timing when I changed things.

fungus


To get this stable I think the whole videoline needs to be written in assembler, from sync to the last pixel.
That way you know it's rockstable.


Very probably.

As a proof of concept though, this is good.

(Assuming the 17th clock cycle thing is fixable).
No, I don't answer questions sent in private messages (but I do accept thank-you notes...)

janost

If I put a While (c--) {NOP; } , what resolution in clockcycles would I get asuming c is a byte and the NOP; is ASM?

janost

I managed to get the white bar down to 4pixels just by moving code around without changing any of the statements.

I hate this compiler and I dont know why i'm pursuing someone else code?

I just need for this to work before I go more advanced.

janost

Some code in this line makes a wait longer than 16 cycles before loading the first byte in the shifter.
That's what is making the White bar.

Code: [Select]

UDR0 = pgm_read_byte (linePtr + (* messagePtr++));

fungus

I use this batch file to disassemble programs and look at the compiled code.

Save it as "disassemble.bat" (or whatever...)

Code: [Select]

rem This is where you installed the Arduino IDE
set avr="c:\Program files\arduino-1.0.5\hardware\tools\avr\bin\avr-"

rem This is "build.path" from your preferences file
set build="h:\temp\arduino\build\"

rem This is the name of your sketch
set target=blink

rem Disassemble the program
%avr%objdump.exe -S -z %build%%target%.cpp.elf >disassembly_elf.txt

rem Show memory usage
%avr%nm.exe -S %build%%target%.cpp.elf >nm_out.txt

No, I don't answer questions sent in private messages (but I do accept thank-you notes...)

nickgammon

This code appears to output successfully every 16 cycles:

Code: [Select]

const byte pixelPin = 1;     // <------- Pixel data
const byte MSPIM_SCK = 4;    // <--  clock
const byte vSyncPin = 10;    // <------- VSYNC

const byte enable = 7;

void setup()
  {
  // Set up USART in SPI mode (MSPIM)
 
  // baud rate must be zero before enabling the transmitter
  UBRR0 = 0;  // USART Baud Rate Register
  pinMode (MSPIM_SCK, OUTPUT);   // set XCK pin as output to enable master mode
  UCSR0B = 0;
  UCSR0C = bit (UMSEL00) | bit (UMSEL01) | bit (UCPHA0) | bit (UCPOL0);  // Master SPI mode

  digitalWrite (enable, HIGH);
  pinMode (enable, OUTPUT);

}  // end of setup

#define nop asm volatile ("nop")

void loop()
  {
  int i = 255;
  digitalWrite (enable, LOW);
 
  // turn transmitter on
  UCSR0B = bit (TXEN0);  // transmit enable (starts transmitting white)
 
  while (i--)
    {
    UDR0 = i;
    nop; nop;
    nop; nop;
    nop; nop;
    nop; nop;
    }

  // wait till done   
  while (!(UCSR0A & bit(TXC0)))
    {}
 
  // disable transmit
  UCSR0B = 0;   // drop back to black

  digitalWrite (enable, HIGH);

}  // end of loop


Eyeballing the results in the logic analyzer it looks like the data is OK.

Code: [Select]

114:   01 97           sbiw    r24, 0x01       ; 1   (2)
116:   80 93 c6 00     sts     0x00C6, r24   (2)
11a:   00 00           nop   (1)
11c:   00 00           nop   (1)
11e:   00 00           nop   (1)
120:   00 00           nop   (1)
122:   00 00           nop   (1)
124:   00 00           nop   (1)
126:   00 00           nop   (1)
128:   00 00           nop   (1)
12a:   00 97           sbiw    r24, 0x00       ; 0   (2)
12c:   99 f7           brne    .-26            ; 0x114 <loop+0x14>   (1/2)


Quote

Some code in this line makes a wait longer than 16 cycles before loading the first byte in the shifter.


Do you mean for the first character or every character?
Please post technical questions on the forum, not by personal message. Thanks!

More info: http://www.gammon.com.au/electronics

janost

OMG! It works!
Managed to get Nick's shiftloader to work by shuffling around line statments in the code.

Its not optimal and uses both plaster and glue but the size is a fraction of the TVout library but with a text resolution of 40x25 and a gfx resolution of 160x100.

The 5" LCD screen does by no way like an 8MHz pixelclock but this is so cool :)

Now its time to optimize :)

miker00lz

Man, this is looking great! Glad somebody is using my 6502 emulator. I'm really looking forward to seeing how far you can take this.

Go Up