[refraction]

uhm, somethings going wierd with the compiler.

my code

spr 0x1007 ; 14x16 - 128 bytes
ldi r0, 15
ldi r1, 0
ldi r2, 0
ldi r3, 0
ldi r4, 128
ldi r5, 512 ;memory base of sprite

the output

OPcode 4
Set Sprite H = 10 W = e
OPcode 20
Load Imm to X(0), imm = f, PC c
OPcode 20
Load Imm to X(1), imm = 0, PC 10
OPcode 20
Load Imm to X(2), imm = 0, PC 14
OPcode 20
Load Imm to X(3), imm = 0, PC 18
OPcode 20
Load Imm to X(4), imm = 7f, PC 1c
OPcode 20
Load Imm to X(5), imm = 1fb, PC 20

checked in the file and it is definately using the immediate of 7f (127) and 1fb(507) instead of the values i asked it to use...

 

[tykel]

I am unable to reproduce your bug, refraction. What version of the assembler do you have? Latest is 1.3.3 (compile with -v to check).

Latest versions here.

I'm on linux btw.

 

[refraction]

I downloaded the 1.3.3 (as you have it written) windows binary and it only seems to affect LDI (altho i havent tried the other load instructions), add etc work fine, infact im now using andi's and ori's to set the values and its fine

tchip16 1.3.3 -- a chip16 assembler
Building tokens... OK
Output code... OK
Output imports... OK

Build complete.

 

[tykel]

I downloaded the 1.3.3 (as you have it written) windows binary and it only seems to affect LDI (altho i havent tried the other load instructions), add etc work fine, infact im now using andi's and ori's to set the values and its fine

I disassembled the binary produced by the code you posted, and all the numbers were alright. Could you post a disassembly of your binary?

Here's what I get:

[tim@darkbox] tchip16 $ cat test.s
spr 0x1007 ; 14x16 - 128 bytes
ldi r0, 15
ldi r1, 0
ldi r2, 0
ldi r3, 0
ldi r4, 128
ldi r5, 512 ;memory base of sprite

[tim@darkbox] tchip16 $ tchip16 test.s -v
tchip16 1.3.3 -- a chip16 assembler
Building tokens... OK
Output code... OK
Output imports... OK

Build complete.

[tim@darkbox] tchip16 $ hd output.c16 
00000000  04 00 07 10 20 00 0f 00  20 01 00 00 20 02 00 00  |.... ... ... ...|
00000010  20 03 00 00 20 04 80 00  20 05 00 02              | ... ... ...|
0000001c

As you can see, loads 80h = 128 and 200h = 512.

 

[refraction]

have the file this is doing exactly the same as the code i gave you (dont have a decent disassembler here) but youll see mine is coming out wrong :S

 

[tykel]

Oh dear... Do you have a decent compiler? You might want to build tchip16 from source.
I'm pretty sure you use SVN (PCSX2), so see the Google Code link I gave you so you can checkout a copy.
Hope that helps!

 

[refraction]

Im afraid i only have visual studio 2010 express here

Edit: Seems i lied, its pretty consistantly doing it with ori too... something isnt happy :/

 

[tykel]

Im afraid i only have visual studio 2010 express here

Edit: Seems i lied, its pretty consistantly doing it with ori too... something isnt happy :/

Compile this and tell me what happens. If it's still bugged I'll take a look

 

[refraction]

Havent recompiled it yet but heres a tidbit for you, the debug version of the windows compiler that was in the package, gets it right

Token array:
    11 : [ cls ]
    12 : [ spr ] [ 0x0707 ]
    13 : [ ldi_r ] [ r0 ] [ 16 ]
    14 : [ ldi_r ] [ r1 ] [ 0 ]
    15 : [ ldi_r ] [ r2 ] [ 0 ]
    16 : [ ldi_r ] [ r3 ] [ 0 ]
    17 : [ ldi_r ] [ r4 ] [ 128 ]
    18 : [ ldi_r ] [ r5 ] [ 512 ]
    21 : [ stm_r ] [ r3 ] [ r5 ]
    22 : [ addi ] [ r5 ] [ 1 ]

but the output is still wrong (this is a new machine now), go figure ;p

Edit: Ok recompiled the assemlber under Visual studio 2010, had to remove a couple of inlines but it works.

Assembly gives the correct result with this so im posting it up for others to use

 

[tykel]

Havent recompiled it yet but heres a tidbit for you, the debug version of the windows compiler that was in the package, gets it right

Token array:
    11 : [ cls ]
    12 : [ spr ] [ 0x0707 ]
    13 : [ ldi_r ] [ r0 ] [ 16 ]
    14 : [ ldi_r ] [ r1 ] [ 0 ]
    15 : [ ldi_r ] [ r2 ] [ 0 ]
    16 : [ ldi_r ] [ r3 ] [ 0 ]
    17 : [ ldi_r ] [ r4 ] [ 128 ]
    18 : [ ldi_r ] [ r5 ] [ 512 ]
    21 : [ stm_r ] [ r3 ] [ r5 ]
    22 : [ addi ] [ r5 ] [ 1 ]

but the output is still wrong (this is a new machine now), go figure ;p

Edit: Ok recompiled the assembler under Visual studio 2010, had to remove a couple of inlines but it works.

Assembly gives the correct result with this so im posting it up for others to use

Good. Could you possibly include a debug binary, and I'll upload this to the tchip16 page?

 

[refraction]

Here you go mate

 

[tykel]

Here you go mate

Cheers

 

[refraction]

I have a small question regarding the new PAL opcode stuff. Are we saying colour 0 will always be transparent? I need to know because im working with alpha channels and most my code makes sure its > 0 to make pixels lol

 

[tykel]

I have a small question regarding the new PAL opcode stuff. Are we saying colour 0 will always be transparent? I need to know because im working with alpha channels and most my code makes sure its > 0 to make pixels lol

Yes, colour index 0 is always transparent in the foreground, whatever palette you use. It will only change how it is used if it's the background colour.

 

[refraction]

Right! Palate Flip Test V1.0

this is essentially taking the original palate and turning it upside down. Im not sure on the order in my .bin files, but if i read them in byte at a time, this is how they fit nicely on my array of pixel colours/palate in my emu (you can see from my previous releases)

So hopefully itll help people implement this neways

Edit: attached a rom called 1.1 spec for those who've implemented headers (or want to)

 

[refraction]

sorry to double post but i has a sound test for you! its a simple ADSR tester that has the following settings

1000hz
a = 10
d = 8
v = 15
s = 15
r = 8
play time = 800ms
play time with release = 1550 ms

itll do all 4 wave forms in loop form, one after the other. hope it helps people implement it

Again included one with no header for people who havent got header support yet (mine isnt implemented properly, just blag round it lol)


Edit: RefChip16 updated!! Get it here to see what the new spec is (kind of) like http://forums.ngemu.com/showpost.php?p=2008479&postcount=50

 

[tykel]

Thank you refraction, very much appreciated. Will test your emu and roms when I get back to windows

EDIT: Headers are mainly to identify if the emu supports the spec revision. So if your emu is constantly up-to-date with the spec, it isn't much of an issue. Start addresses would be interesting if adopted more widely.

Also made your RefChip16 the reference emulator, since it is now up-to-date with the spec. Will try to get mine out sometime in April!

 

[refraction]

You're very welcome, if you need anything, feel free to ask

Good luck with your emulator! I guess at some point ill do a sort of rom info popup thing showing off the spec stuff, i guess version checking would be good before the next version is released!

Edit: just did a quick update on my emu to stop any spec higher than 1.1 being used and made the header stuff global for more nice stuff in the future

 

[tykel]

There seems to be a speed issue with the Static demo.
Also, I can't see what the PaletteFlip demo does, all I see is a single band of colours on the left.
Finally, I get pixel distortion (pretty bad in some cases, see Maze): any way to improve this, or give a scale option?

Apart from that, good job (digging the AdsrTest!)

 

[refraction]

Is this on my emu? Odd! There isn't a huge c16log.txt in the root of your c drive is there?


With palate test, you use up and down to flip the palate (w and s) just to show an example of palate swapping )

Edit: Just checked, V1.08 i have up at the moment is fine with Maze and Starfield, so i dont know whats happening there mate

Edit 2: Kinda see what you mean about Maze, directx does some wierd thing with pixel sizes, i notice it on the cross in the collision demo too, not sure how to sort that