palmheads

Hi all Came up with this interesting solution (almost by accident!) for connecting my PAL TI to a PAL Commodore 1702 monitor with no mods. I thought I'd forget completely about trying to connect to the 1702, & had an idea to search for a portable DVD player with a PAL TV tuner. Sure enough, I found one. Wasn't sure if it would work, but was cheap enough so went ahead & purchased it. http://www.amazon.com/gp/product/B008HYWFA4?psc=1&redirect=true&ref_=oh_aui_detailpage_o02_s00 Arrived today. Plugged it into the TI, manually tuned it in. It worked! Then I realised in the package of the DVD players, they had cables for AV out with the 3 colour vid/sound etc plugs. Plugged those into the 1702 monitor, and that worked also!!! So now have this interesting set-up with the TI displaying on both a portable DVD player and the 1702 monitor. See attached picces. cheers Daryn

Great watch! Well worth reading "Ready Player One" by Ernest Kline (the guy with the De Lorean in the doco). Great retro book! cheers Daryn

Yeah they've been in that state for a few weeks. You can actually still get paths to docos etc though http://webpages.charter.net/nanopeb/downloads/ cheers Daryn

Cheers, thanks Rasmus - will see if I can figure this out given your advice. Will report back when done! Thanks mate! Daryn

Hi all Got my nanoPEB working, so here is a vid of my game working on real hardware. Only a black & white TV until I get my PAL modulator modded for my Commodore 1702 monitor. Am currently working on getting Sprite->wall collision. Have been thinking through what todo. Does this make sense? The main thrust sprite uses VDP 300/301 locations for its position. These locations are HEX The walls are characters. So they are the 32x24 matrix. Bottom right cnr being 768 To register a collision, would I needed to do a HEX-DECIMAL conversion of the VDP 300/301 locations, then test if the resulting location has a character code located there? I think I am on the right track, just confirming this is the right logic? cheers Daryn

That is amazing Rasmus!!! OMG

Hey everyone! My 32MB Sandisk CF Cards arrived on Friday. Followed process of formatting in TiDir, copying dsk images over etc. Plugged in to nanopeb.... WORKED FIRST TIME! WOOO! So cool seeing my Thrust game I'm porting working on a real machine! Thanks for everyones help here! cheers Daryn

Got another update! Source code attached I implemented the snippet of code Rasmus suggested above for loop timing & sprite collision. Worked great! Have got far more accurate sprite collision thanks to being able to read the status register for collisions. Also was able to remove my dodgy delay loop. Thanks Rasmus! The other thing I was able to figure out was cavern walls. Figured out how to read in the data & display, as well as designing the chars that make them. I have to now figure out how my sprite can trigger a collision with the walls. Thats my next step. Again, thank you everyone for your great advice on this. Been putting in time most days on this, and am enjoying it. cheers Daryn wall2.asm

Thanks so much everyone! Have given all these suggestions for my current card a go, and it looks like it may be incompatible. Have purchased a couple of 32MB Sandisk cards from ebay, so will report back when they arrive. Will go through all these great suggestions again. Thanks again! cheers Daryn

Hi all As the title says, what CF Card would you recommend to use with your nanopeb? I purchased a Kingston 4GB CF Card, and the nanopeb appears to have issues reading from it. I can load DSKs using both TiDIR and xvm99 (part of the xdt99 cross assembler tools). Everything looks sweet at this stage. I've got my 5V adapter plugged in. TI powers up fine with "NANOPEB-F18 V1" on the splash screen. I can go into TI Basic, and type CALL MOUNT(1,1) & it works without Error. However if I try any of my known techniques of accessing any of the DSKs on the CF Card, nothing works. i.e ('WALL' being a file contained within DSK1 loaded to Volume 1) OLD DSK1.WALL * WARNING * CHECK PROGRAM IN MEMORY * I/O ERROR 57 Or using Mini Memory 'LOAD AND RUN' (as I would on js99er & classic99). I can see the middle CF card accessing LED lighting up. LOAD AND RUN DSK1.WALL * ERROR * I/O ERROR CODE 2 PRESS ENTER TO CONTINUE From reading about the nanopeb, it can be real picky about what CF cards work. Reckon I should try a Sandisk 4Gb? Or 4GB too large for this nanopeb? cheers Daryn

Will definitely keep this in mind. At the moment this small change seems to have made the collisions way more accurate, even without tweaking the proxmity stuff for a particular sprite - so much fun getting stuff to work! I feel like a game could actually come out of this! cheers Daryn

Awesome Rasmus - wee investigate this snippet more & see how it could integrate with my (shitty) code! cheers Daryn

Yup think I found how, something like this *------------------------------------------------------------ * VDP read status. Result will be in R0 MSB *------------------------------------------------------------ VRDSTA MOV @>8802,R0 Read status register, resets bits 0-2. B *R11 Delay Just quickly tried it in my code before my proximity checking - sprite collision already feels more accurate cheers Daryn

I think I found it! *------------------------------------------------------------ * VDP read status. Result will be in R0 MSB *------------------------------------------------------------ VRDSTA MOV @>8802,R0 Read status register, resets bits 0-2. B *R11 Delay Seem to work!! WOO! cheers Daryn

Looking at Editor Assembler manual (pg 169), and the Art of Assembly PDF, it looks like an instruction call 'STST' is the one to focus on? Think I am on the right track cheers Daryn

Hi all Think I've found info about the VDP status register, & particular the collision bit. Actually not easy to find info about it. http://www.unige.ch/medecine/nouspikel/ti99/tms9918a.htm Maybe a typo below (should be Bit 2) "...Bit 1 (weight >20) is the coincidence bit. It is set when two sprites or more have at least one overlapping "on" pixel. This occurs even if the sprite color is transparent. Note that coincidence is checked only every 1/60th of second (1/50th of a second for the TMS9929A), thus if you change sprite positions during that time a coincidence could be missed." Just gotta figure out now how to read it cheers Daryn

Sounds like a plan! Will do some investigations, and see whats involved. cheers Daryn

Cheers Mark! Will look into the collision stuff more soon I think. Am gonna see how todo a collision to a cavern wall next, then I'II optimise the collision stuff Am using a small delay loop for the sprite movement delay li r15,500 ;needed time delay dec r15 ;for sprite movement jne $-2

haha - yeah...haven't optimised the sprite collision stuff. Its pretty accurate for the first sprite I put in the screen (the reactor), but for the others its more 'close enuff!' I'II write something a bit better later on, just trying to get the idea of how things work at the moment. cheers Daryn

Hi! OK, got sprite rotation working with moving sprite where its pointing (ie diagional movements, up/down, sideways etc) Very much like Thrust & Asteroids etc Here is a vid: Next step, think I might get some sort of 'wall' collision working. Am not sure how this works. I assume the side of a 'wall' aren't sprites. I'd imagine its some sort of character/screen definition you define, and a "collision" is where you hit some sort of screen limit? Is that correct? Am not sure, will have todo some research. If anyone wants to also have a play, here is my code so far aorg >a000 ;starting loc for mini mem '7d00' lwpi >70b8 ;load registers li r0,>0384 li r1,>1100 ;set background screen colour black blwp @>6024 li r0,>0420 li r1,dataf ;sprite 0 def starting sprite li r2,412 blwp @>6028 li r0,>0300 li r1,datat ;sprite 0 attr li r2,21 blwp @>6028 li r0,>01e2 ;sprite magnify 3 swpb r0 ;once interupts enabled, need this movb r0,@>83d4 ;and this because kscan is used swpb r0 ;and this, because r1 is used blwp @>6034 clr @>8374 ;clearing for keyscan li r7,>0000 ;record where sprite is li r13,00 loop limi 2 limi 0 bl @keyscan ;keyscan updatat li r0,>0302 ;rotate through sprites mov r13,r1 sla r1,2 ai r1,>84 swpb r1 li r2,2 ;send 2 bytes blwp @>6024 ;write bytes back jgt loop rotl inc r13 andi r13,7 li r15,8000 ;needed time delay dec r15 ;for sprite rotation jne $-2 jeq updatat rotr dec r13 andi r13,7 li r15,8000 ;needed time delay dec r15 ;for sprite rotation jne $-2 jeq updatat coll swpb r8 ;test thrust sprite about to collide swpb r10 s r10,r8 ;subtract registes abs r8 ;absolute value ci r8,>000e ;compare with 0e b *11 collsp inc r9 ;check next sprite ci r9,>0005 ;one more than num sprites on screen. find way of ;counting this jeq loop ;start game loop again clr r8 ;look at sprite attr table clr r10 ;increments of 4 mov r9,r5 ;get next incr of r4/r5 sla r5,2 ;r5 being sprite # 1,2 etc li r0,>0300 ;vdp 304 - 308 a r5,r0 blwp @>602c movb r1,r10 movb r14,r8 bl @coll jgt collsp ;not hitting, check next sprite ;possible collision, check row clr r8 clr r10 inc r0 ;vdp 305 - 309 range blwp @>602c movb r1,r10 movb r7,r8 bl @coll jgt loop ;got a collision here! hit li r0,>0302 li r1,>a800 ;char code of collision sprite blwp @>6024 ;write bytes back li r15,10000 ;needed time delay dec r15 ;for sprite rotation jne $-2 b @>a000 ;reset game - back to start keyscan blwp @>6020 ;keyscan clr r3 mov @>8374,r3 ;ascii key to r3 ci r3,69 ;e key jne $+42 li r0,>0300 ;move along col clr r14 ;prepare r7 for row value blwp @>602c ;read row value movb r1,r14 bl @thrustc blwp @>6024 ;write to sprite attr li r0,>0301 ;move along col clr r7 ;prepare r7 for row value blwp @>602c ;read row value movb r1,r7 ;move to left byte of r1 bl @thrustr blwp @>6024 ;write to sprite attr ;rotate keys ci r3,90 ;z key - rotate jne $+4 jeq rotl ci r3,67 ;c key - rotate jne $+4 jeq rotr delay li r15,500 ;needed time delay dec r15 ;for sprite movement jne $-2 li r9,0 bl @collsp ;b *11 ;back to loop ;different points of rotation ;mean different pixel movements thrustc ci r13,0 jne $+6 ai r1,->0100 ci r13,1 jne $+6 ai r1,->0100 ci r13,2 jne $+6 ai r1,>0000 ci r13,3 jne $+6 ai r1,>0100 ci r13,4 jne $+6 ai r1,>0100 ci r13,5 jne $+6 ai r1,>0100 ci r13,6 jne $+6 ai r1,>0000 ci r13,7 jne $+6 ai r1,->0100 b *11 thrustr ci r13,0 jne $+6 ai r1,>0000 ci r13,1 jne $+6 ai r1,->0100 ci r13,2 jne $+6 ai r1,->0100 ci r13,3 jne $+6 ai r1,->0100 ci r13,4 jne $+6 ai r1,>0000 ci r13,5 jne $+6 ai r1,>0100 ci r13,6 jne $+6 ai r1,>0100 ci r13,7 jne $+6 ai r1,>0100 b *11 dataf data >0102,>0204,>0408,>0810 ;sprite 0 - 4 cnrs data >1060,>8040,>2023,>1408 ;main thrust sprite data >0080,>8040,>4020,>2010 data >100c,>0204,>0888,>5020 data >3028,>2423,>2020,>2020 ;top left data >2020,>4080,>4132,>0a04 data >0000,>0000,>8040,>3804 data >0408,>0810,>d020,>0000 data >0000,>0000,>0106,>1860 ;left data >8060,>1806,>0100,>0000 data >0020,>504c,>8201,>0204 data >0404,>0201,>824c,>5020 data >0000,>0102,>0202,>0408 ;bottom left data >1010,>2040,>80ff,>0000 data >0000,>8060,>1804,>0808 data >0806,>0102,>04c4,>2810 data >040a,>1110,>2040,>3008 data >0804,>0402,>0201,>0100 ;sprite 1 data >1028,>c404,>0201,>0608 ;reverse main sprite data >0810,>1020,>2040,>4080 data >0000,>040b,>0810,>1020 ;bottom right data >201c,>0201,>0000,>0000 data >2050,>4c82,>0102,>0404 data >0404,>0404,>c424,>140c data >040a,>3241,>8040,>2020 ;right data >2040,>8041,>320a,>0400 data >0000,>0080,>6018,>0601 data >0618,>6080,>0000,>0000 data >0000,>0000,>0102,>1c20 ;top right data >2010,>1008,>0b04,>0000 data >0c14,>24c4,>0404,>0404 data >0404,>0201,>824c,>5020 data >0007,>1820,>4040,>8080 ;reactor data >8040,>4020,>ff80,>b0b0 data >0c80,>6e1a,>0a0a,>0b0b data >0b0b,>0a0a,>fb01,>0101 data >8163,>7f3f,>222e,>6ee6 ;ship collision data >ee6e,>2e22,>3f7f,>6381 data >81c6,>fefc,>d4d4,>b677 data >77b6,>dcd4,>fcfe,>c681 data >0000,>0000,>1966,>81f8 ;gun turret data >0700,>0000,>0000,>0000 data >0000,>0000,>c030,>8864 data >1cc6,>3109,>0905,>0503 data >1f60,>80b5,>a5b5,>a5a7 ;fuel data >8080,>8080,>8080,>8080 data >f806,>0169,>4969,>496d data >0101,>0101,>0101,>0101 data >0000,>0000,>030c,>1126 ;gun turret 2 data >3863,>8c90,>90a0,>a0c0 data >0000,>0000,>9866,>811f data >e000,>0000,>0000,>0000 datat data >0000,>840a ;thrust ship data >5030,>a404 ;reactor data >7080,>ac0d ;turret data >1010,>b007 ;fuel data >9080,>b40d ;turret data >d000 aorg >701c data >7d1e data >7fe0 aorg >7fe0 text 'UPTHRU' ;name of program data >a000 ;starting location end up.asm

One cool thing I've found is, with using xdt99 to compile an object I can then add to a disk image, then upload that disk image too js99'er for testing. Because I'm using the mini memory module to load object from DSK1, and because I'm actually starting my code at A000 so I using the 32k console ram (so not actually using the mini memory from 7d00), using DISK2 I can actually have the line by line assembler just sitting there as well. Its been quite handy if I want to see how many bytes to jump ahead with a JNE or something. I can enter the snippet of code (generally only 5-10 lines), & then I can actually see how many bytes from start to end of the code (as the LBLA assembles each line, it tells you how many bytes its jumped ahead for each statement). cheers Daryn

I got this to (kinda) work in the weekend. However it looks ghastly (sprite jumping all over the show) so needs more work! ha So no vid until it doesn't make your eyes bleed cheers Daryn

Am currently working on getting main thrust sprite move in the direction the sprite is pointing (a la asteriods, thrust itself). So moving diagonally etc Reckon I know what todo as well! Will try this weekend to get it going! cheers Daryn

Helps having good examples to get you started, thats for sure. Thats why I intend just having my source code available to look at. Am no doubt doing things in an inefficient way with the code, but the hardest thing is getting started half the time. And that includes the dev environment you choose. cheers Daryn

I should add am using GraphiCV also as the sprite editor cheers Daryn