palmheads
-
Content Count
211 -
Joined
-
Last visited
Posts posted by palmheads
-
-
Is your 1702 a U.S. spec monitor that takes NTSC, or a PAL 1702?
If it is a NTSC unit, then yes, a U.S. 99/4A will work great, but will obviously need a voltage converter for New Zealand, or a local 230V TI power supply. You are right that the monitor cable from a Commodore 64 or Sega SC3000H should work fine. I am assuming your cable is the 5-pin version, and not the 8-pin one used on later Commodore 64s.
If you have a PAL 1702 and you did get a U.K. spec TI99/4A it still would not work.
The PAL 99/4As used the TMS9929A chip which did not produce composite output. The 6-pin plug on the unit outputs an RGB style signal that is converted to RF by the modulator. There used to be a mod that allowed you to take composite video from inside the modulator, but I cannot find it now.
Ah interesting! Thanks everybody for all the information
One of the guys at work has a PAL TI - I think I can borrow it & see what does/doesn't happen.
Will also have a close look the 1702 - I'm pretty sure it would be a PAL one.The C64 it came with was a NZ one.
cheers
Daryn
-
1
-
-
Hey all
I've got a Commodore 1702 monitor here at home. Am in New Zealand, but I think if I got a US TI-99/4a the whole PAL/NTSC issue goes out the window huh with the appropriate monitor cable. Is my assumption correct?
I may even have a compatible monitor cable already, as my C64 & Sega SC3000H both connect to the 1702.
However, looks like cables like this:
May be all I need.
Its quite hard to see UK TI's on ebay, and very few people seem to ship overseas from there. Loads of US TI's though.
cheers
Daryn
-
That is a super game all right! Terrific mini memory game!
Its really addictive
cheers
Daryn
-
I think I'II leave the physics elements of 'Thrust' until the end. Basics first! More knowledge in assembly needed before I tackle that complexity.
Next thing I'II work on is too have my sprite collide with another sprite and maybe a wall!
Small steps, but slowly getting the hang of it.
cheers
Daryn
OK got some pretty basic collision detection working with sprite collision - demo just freezes (on purpose) when sprite my "Thrust" sprite hits the "Reactor" sprite
aorg >7d00 ;starting loc for mini mem lwpi >70b8 ;load registers li r0,>0420 li r1,dataf ;sprite 0 def starting sprite li r2,288 blwp @>6028 li r0,>0300 li r1,datat ;sprite 0 attr li r2,9 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 blwp @>6020 ;keyscan clr r3 mov @>8374,r3 ;ascii key to r3 li r0,>0300 ;move along col clr r7 ;prepare r7 for row value blwp @>602c ;read col value swpb r1 movb r1,r14 ;up and down keys ci r3,69 ;e key jne $+10 ai r1,->0100 ;move up blwp @>6024 ;write to sprite attr ci r3,88 ;x key jne $+10 ai r1,>0100 ;move down blwp @>6024 ;write to sprite attr li r0,>0301 ;move along row clr r7 ;prepare r7 for row value blwp @>602c ;read row value movb r1,r7 ;move to left byte of r1 ;left and right keys ci r3,83 ;s key jne $+10 ai r1,->0100 ;move left blwp @>6024 ;write to sprite attr ci r3,68 ;d key jne $+10 ai r1,>0100 ;move right blwp @>6024 ;write to sprite attr ;rotate keys ci r3,90 ;z key - rotate jne $+8 jeq rotl blwp @>6024 ;write to sprite attr ci r3,67 ;c key - rotate jne $+8 jeq rotr blwp @>6024 ;write to sprite attr li r15,500 ;needed time delay dec r15 ;for sprite movement jne $-2 ;possible crash clr r8 ;collision detection clr r10 movb r14,r8 swpb r8 clr r10 li r0,>0304 blwp @>602c movb r1,r10 swpb r10 s r10,r8 abs r8 ci r8,>000e jgt loop clr r8 movb r7,r8 swpb r8 clr r10 li r0,>0305 blwp @>602c movb r1,r10 swpb r10 s r10,r8 abs r8 ci r8,>000e jgt loop ;got a collision!!! jmp $ ;freeze screen updatat li r0,>0302 mov r13,r1 sla r1,2 ai r1,>84 swpb r1 li r2,2 ;send 2 bytes blwp @>6024 ;write bytes back jmp 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 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,>0a0a data >0a0a,>0a0a,>fb01,>0101 datat data >0000,>8401,>5030,>a404,>d000 ;8401 - black aorg >701c data >7d1e data >7fe0 aorg >7fe0 text 'COLLID' ;name of program data >7d00 ;starting location end
Next thing to work on - cavern wall detection!
I guess for this you set an out of bounds error within the screen (i.e some sort of contraint) where the if the sprite hits the "wall" its a collision?
Will give it a go!
cheers
Daryn
-
1
-
-
Just had a thought for a small enhancement to js99er. How about a mobile friendly icon when you bookmark it?
On Android at least, you can send Chrome bookmarks to the screen. Some mobile sites have nice "app" like icons for their mobile sites.
Example:
cheers
Daryn
-
Hey Rasmus - have implemented something that almost exactly matches your first suggestion above - won't post anything until I get all 8 sprites rotating (was testing with just two) - took a while to figure out howto change character code in sprite attribute table, but once figured that out was ok
Will work in the 8 sprites next week & have a (hopefully) nice example to show
cheers
Daryn
Got something mostly working with sprite rotation. Not perfect, but can improve on it over time.
Rotate Left: Z
Rotate Right: C
TI arrows keys up/down/left/right
aorg >7d00 ;starting loc for mini mem lwpi >70b8 ;load registers li r0,>0420 li r1,df ;sprite 0 def starting sprite li r2,256 blwp @>6028 li r0,>0300 li r1,dt ;sprite 0 attr li r2,5 blwp @>6028 li r0,>01e2 ;sprite magnify 2 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 lp limi 2 limi 0 ks blwp @>6020 ;keyscan clr r3 mov @>8374,r3 ;ascii key to r3 li r0,>0301 ;move along row clr r7 ;prepare r7 for row value blwp @>602c ;read row value movb r1,r7 ;move to left byte of r1 ci r3,83 ;s key jne $+10 ai r1,->0100 ;move left blwp @>6024 ;write to sprite attr ci r3,68 ;d key jne $+10 ai r1,>0100 ;move right blwp @>6024 ;write to sprite attr li r0,>0300 ;move along col blwp @>602c ;read col value swpb r1 ;move to right byte of r1 ci r3,69 ;e key jne $+10 ai r1,->0100 ;move up blwp @>6024 ;write to sprite attr ci r3,88 ;x key jne $+10 ai r1,>0100 ;move down blwp @>6024 ;write to sprite attr ci r3,90 ;z key - rotate jne $+8 jeq rl blwp @>6024 ;write to sprite attr ci r3,67 ;c key - rotate jne $+8 jeq rr blwp @>6024 ;write to sprite attr li r15,500 ;needed time delay dec r15 ;for sprite movement jne $-2 jmp lp ut li r0,>0302 mov r13,r1 sla r1,2 ai r1,>84 swpb r1 li r2,2 ;send 2 bytes blwp @>6024 ;write bytes back jmp ks rl inc r13 andi r13,7 li r15,8000 ;needed time delay dec r15 ;for sprite rotation jne $-2 jeq ut rr dec r13 andi r13,7 li r15,8000 ;needed time delay dec r15 ;for sprite rotation jne $-2 jeq ut df 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 dt data >0000,>8401,>d000 ;8401 - black aorg >701c data >7d1e data >7fe0 aorg >7fe0 text 'ROTATE' ;name of program data >7d00 ;starting location end
I think I'II leave the physics elements of 'Thrust' until the end. Basics first! More knowledge in assembly needed before I tackle that complexity.
Next thing I'II work on is too have my sprite collide with another sprite and maybe a wall!
Small steps, but slowly getting the hang of it.
cheers
Daryn
-
Yep, you upload the 8 sprite patterns to the VDP at the beginning of your code and then update the 3rd byte of the sprite attributes (the one that currently contains the value >84) to change the displayed pattern. You need to allocate a new register, e.g. R9, for holding the currently displayed animation frame. Instead of storing the actual attribute value (>8400, >8800, >8C00, etc) I think it would be easier to store a simple number 0, 1, 2 ... 7. Then you can use INC R9, and DEC R9 to rotate left or right followed by ANDI R9,7 to make sure you stay within the interval 0-7 and wrap around if you go outside. When you get to the point where you want to change the actual VDP byte you do something like this first:
MOV R9,R1 ; We need the number in R1 SLA R1,2 ; Multiply by 4 AI R1,>84 ; Add base attribute value SWPB R1 ; Move into high byte
Instead of waiting using an arbitrary loop you could also wait for vertical retrace (EDIT: you will probably need to turn off interrupts with LIMI 0 for this to work):
CLR R12 VSYNC TB 2 ; Test CRU bit for VDP interrupt JEQ VSYNC MOVB @>8802,R0 ; Read the VDP status reg to reset interrupt bitHey Rasmus - have implemented something that almost exactly matches your first suggestion above - won't post anything until I get all 8 sprites rotating (was testing with just two) - took a while to figure out howto change character code in sprite attribute table, but once figured that out was ok
Will work in the 8 sprites next week & have a (hopefully) nice example to show
cheers
Daryn
-
3
-
-
Yep, you upload the 8 sprite patterns to the VDP at the beginning of your code and then update the 3rd byte of the sprite attributes (the one that currently contains the value >84) to change the displayed pattern. You need to allocate a new register, e.g. R9, for holding the currently displayed animation frame. Instead of storing the actual attribute value (>8400, >8800, >8C00, etc) I think it would be easier to store a simple number 0, 1, 2 ... 7. Then you can use INC R9, and DEC R9 to rotate left or right followed by ANDI R9,7 to make sure you stay within the interval 0-7 and wrap around if you go outside. When you get to the point where you want to change the actual VDP byte you do something like this first:
MOV R9,R1 ; We need the number in R1 SLA R1,2 ; Multiply by 4 AI R1,>84 ; Add base attribute value SWPB R1 ; Move into high byte
Instead of waiting using an arbitrary loop you could also wait for vertical retrace (EDIT: you will probably need to turn off interrupts with LIMI 0 for this to work):
CLR R12 VSYNC TB 2 ; Test CRU bit for VDP interrupt JEQ VSYNC MOVB @>8802,R0 ; Read the VDP status reg to reset interrupt bitCheers Rasmus, will give this a go this week. I kinda had an idea that was the way to go. Having these code snippets are fantastic, I can go away & give it a nudge getting to work, and its slowly making more and more sense whats happening as well.
Have had this "dream" to make a game for years, but the combo of your js99'er, xdt99 cross assembler, this mailing list, and the Lottrup book and even the TI hardware/TMS9900 have kinda hit the sweetspot in terms of development. Have tried to learn Z80 on my ZX81/Sega SC3000H but its always stalled because even knowing where to start was a stumbling block. But thus far with the TI, feels like am on the right track.
Thanks for all the hints
cheers
Daryn
-
Daryn,
I'm glad you like it -- and I like the script you created for simplifying the edit-assemble-run cycle. I think that's one of the big advantages of command-line based tools: you can easily combine and tweak them so that they meet exactly your needs.
Note that I'll keep updating the tools without explicit announcements here in the forum, so check the GitHub release page once in a while for new features available.
Will keep on eye out on your github page ralphb
I think these tools have sped up my learning process. Can write my assembly using vim, add to disk, upload to js99'er and see results really quickly. Makes a huge difference, especially when examples you see elsewhere in books/code examples etc that you plug into your code assemble & just work.
So many times the learning process stops because the tools/examples etc just don't work (or at least not in an intuitive way).
Again, thanks so much for xdt99
cheers
Daryn
-
Cool. But remember that >0016 is 22 in decimal. You'll probably want a smaller jump value. Try 4.
Good to see someone getting down and dirty with assembly language!
Cheers Willsy!
OK am starting to feel real good about this!!
While I could move my sprite around, it would jump around a bit as I moved left/right & up/down. I realised my code wasn't recording the last known row/col counters. Was looking at another example in the Lottrup book regarding collision detection, and noticed some code that shifted row/col coords to the left/right of register 1.
So put those bits of code in a similar place in mine, and it WORKED!!!
I also used Rasmus's suggestion of an increment of >0100 (with a delay timer so you can actually see the sprite!).
Now I can move my sprite 1 pixel up/down/left/right using arrow keys smoothly with no jumps! Fantastic!!! So exciting getting to the point of looking at some code, kinda figuring out what it might do, implementing it, and it working!!
Here is my code:
aorg >7d00 ;starting loc for mini mem lwpi >70b8 ;load registers li r0,>0420 li r1,df ;sprite 0 def li r2,32 blwp @>6028 li r0,>0300 li r1,dt ;sprite 0 attr li r2,5 blwp @>6028 li r0,>01e2 ;sprite magnify 2 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 ;row register li r8,>0000 ;col register lp limi 2 limi 0 blwp @>6020 ;keyscan clr r3 mov @>8374,r3 ;ascii key to r3 li r0,>0301 ;move along row clr r7 ;prepare r7 for row value blwp @>602c ;read row value movb r1,r7 ;move to left byte of r1 ci r3,83 ;s key jne $+10 ai r1,->0100 ;move left blwp @>6024 ;write to sprite attr ci r3,68 ;d key jne $+10 ai r1,>0100 ;move right blwp @>6024 ;write to sprite attr li r0,>0300 ;move along col blwp @>602c ;read col value swpb r1 ;move to right byte of r1 ci r3,69 ;e key jne $+10 ai r1,->0100 ;move up blwp @>6024 ;write to sprite attr ci r3,88 ;x key jne $+10 ai r1,>0100 ;move down blwp @>6024 ;write to sprite attr li r15,500 ;needed key delay dec r15 jne $-2 jmp lp df 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 dt data >0000,>8401,>d000 aorg >701c data >7d1e data >7fe0 aorg >7fe0 text 'SPRITE' ;name of program data >7d00 ;starting location end
Ok so the next thing I might do is change the way my sprite moves.
I want my sprite to rotate (a la 'Asteroids' and 'Thrust'). I think what I need todo is define probably 8 sprites. Each sprite showing a different angle as my 'ship' rotates (using left/right keys). So design the sprites, then figure out how a keyscan and keypress that can choose a different sprite to display.
Is that the basic idea to get a ship rotation working?
cheers
Daryn
-
1
-
-
The AI instruction can only take a VALUE as the second parameter, not a register. If you want to add the value *in* a register to another register then you need the A instruction.
AI R1, 10 - correct
AI R1, R10 - incorrect. Must be a value not a register.
A R1, R10 adds the value in R1 to R10, leaving the result in R10
HTH
Ah cool, that makes sense. My intent for my AI example was to define a constant in a register (in my case a 16 pixel movement), and then add/sub
So this is good
ai r1,>0016 ai r1,->0016
What I was doing here is bad
li r14,>0016 ai r1,r14 ;move right ai r1,-r14 ;move left
thanks Willsy & Rasmus, that makes sense!
cheers
Daryn
-
Have a look at the Editor/Assembler manual on page 326 and pages 404-406. Long ago, when I did my first steps in assembly language, these pages really confused me, and they are a quite good example for bad documentation.
What TI writes here is not really wrong, but they do not reveal the context where this information is meaningful. In particular, when you keep full control over your program, you certainly do not have to copy the value to 83D4. However, as soon as you allow interrupts with LIMI 2, the interrupt handler gets into action.
Patching your code:
li r0,>01e2 ; sprite magnify 2 swpb r0 movb r0,@>83d4 swpb r0 blwp @>6034
WOOO!
That is fantastic! So I guess once you enable interupts for things like keypress recognition, this needs to happen everytime?
Thanks so much mizapf - works great!
Now have to figure out why it jumps ahead a few pixels as I'm moving the sprite around.
Thank you so much!
cheers
Daryn
-
If you set video register 1 and you allow interrupts, you must copy its value to 83D4 before because the interrupt handler will copy that value to register 1 when you press a key.
Hi mizapf
So would doing a MOV/MOVB do that? Something like this?
movb r1,@>83D4
Will have a play!
cheers
Daryn
-
I'm not sure I'm able to follow your code, but these lines "ai r1,r14" and "ai r1,-r14" look a bit strange. Should you be using "a r14,r1" and "s r14,r1" instead?
Hi Rasmus
For that was using an example from the Lottrup assembly language book, with my own mod
From the book, the first "Add Immediate" line moves my sprite 16 pixels to the right. From the book, you can add a minus to effectively have a "Subtract Immediate", so the second with the '-' moves it 16 pixels to the left
ai r1,>0016 ai r1,->0016
I made a small mod, instead of having to type '>0016' 4 times, I assigned it to register 14
li r14,>0016 ai r1,r14 ;move right ai r1,-r14 ;move left
I dunno if thats the right thing todo, but it does seem to allow me to move my (partial) sprite up/down/left/right.
Was basing all of this from an example in the book where a sprite was scrolled right across the screen, which works perfectly.
aorg >7d00 lwpi >70b8 li r0,>0420 li r1,df li r2,32 blwp @>6028 li r0,>01e2 ;magnify 2 blwp @>6034 li r0,>0300 ;sprite 0 li r1,dt li r2,5 blwp @>6028 li r0,>0301 rs clr r1 lp ai r1,>0100 blwp @>6024 ci r1,>ff00 jeq rs li r15,1000 dec r15 jne $-2 jmp lp df data >0102,>0204,>0408,>0810 data >1060,>8040,>2023,>1408 data >0080,>8040,>4020,>2010 data >100c,>0204,>0888,>5020 dt data >6080,>8401,>d000 end
I don't really know what I'm doing yet, hence my confusion that only part of my sprite is actually getting moved around!
cheers
Daryn
-
Hi all
Got a question. Been trying to get my sprite moving around the screen using the arrow keys (E-S-D-X).
Have more or less got it working, but for some reason my sprite mostly disappears. Its looks like of the 4 data statements to make the sprite, only the top left quadrant actually moves! So the whole sprite appears initially, but then only part of it thereafter.
I can't see what I am doing wrong. Here is my source...
aorg >7d00 lwpi >70b8 ;load registers li r14,>0016 ;pixel movement li r0,>0420 li r1,df ;sprite 0 def li r2,32 blwp @>6028 li r0,>0300 li r1,dt ;sprite 0 attr li r2,5 blwp @>6028 li r0,>01e2 ;sprite magnify 2 blwp @>6034 clr @>8374 ;clearing for keyscan rs clr r1 lp limi 2 limi 0 li r0,>0301 ;row blwp @>6020 ;keyscan clr r3 mov @>8374,r3 ;ascii key ci r3,83 ;s key jne $+10 ai r1,-r14 ;move left blwp @>6024 ci r3,68 ;d key jne $+10 ai r1,r14 ;move right blwp @>6024 li r0,>0300 ;col ci r3,69 ;e key jne $+10 ai r1,-r14 ;move up blwp @>6024 ci r3,88 ;x key jne $+10 ai r1,r14 ;move down blwp @>6024 ci r3,90 ;z key jne $+10 ai r1,r14 ;move down blwp @>6024 jmp lp df data >0102,>0204,>0408,>0810 ; sprite 0 - 4 cnrs data >1060,>8040,>2023,>1408 data >0080,>8040,>4020,>2010 data >100c,>0204,>0888,>5020 dt data >0000,>8401,>d000 aorg >701c data >7d1e data >7fe0 aorg >7fe0 text 'SPRITE' data >7d00 end
Am running it through mini memory (hence the AORG 7D00 etc).
Any ideas what I have missed?
cheers
Daryn
-
I think this has been mentioned before, but the other cool thing about js99er is how cool it is on a mobile. On my Nexus 5 its great, especially with an external keyboard plugged via a USB-OTG port. When you rotate phone to landscape, the screen size of the TI fits almost perfectly. And above all its fast!
The current Droid-99 emulator on Android is broken on the latest lollipop OS, so js99er is even more wonderful!
cheers
Daryn
-
That "Thrust" looks like a fun game!
Yeah its a fantastic game. Its been ported to almost every 8 bit machine known to man.
Graphics are simple, but the gameplay amazing. The physics of the game are great, collecting the orb, it being heavy causing all sorts of momentum mayhem.
Feels like a good fit for the TI, not a huge amount of sprites, all one colour. Am sure with assembly the gameplay would be fast enough. In my example above moving the sprite across the page looked plenty quick to me.
cheers
Daryn
-
So been playing with xdt99, js99er web emulator with mini-memory module loaded and the Lottrup book. Made my own sprite & got it scrolling across the page by using an example in the book
The sprite is the ship off the game "Thrust", magnification 2
See attached motion.asm
Feel like with this I have the start of the building blocks of porting "Thrust" to the TI.
Next step am gonna try being able to move the sprite around the screen. There is an example of something similar in the Lottrup book with a hires sketch app using the arrow keys.
if using xdt99 tools, make object file thus:
./xas99.py -OR motion.asm
Then load object file to a disk image, load & run thru mini-memory. I normally run it thru EasyBug using 'E7D00'
To see "Thrust" the game in action, here is the BBC Micro version
cheers
Daryn
-
4
-
-
That would be great Ksarul - hopefully you have it lying around somewhere!
cheers
Daryn
-
Am really loving xdt99!
Been using it with the examples in the Lottrup assembly language book.
Every single example I've entered in using vim on my Linux box, have compiled, then Load and Run the object file with mini-memory in classic99 & now js99er has worked!
Attached is a hires draw asm example.
Here is a wee perl script wrapper I've written around xas99.py and xdm99.py to compile an object from an asm file, then add it to a DSK image (1 dir up).
name: xdt.pl
#!/usr/bin/perl use strict; use warnings; use Data::Dumper; # ./xas99.py -OR sprites.asm # ./xdm99.py work.dsk -a sprites.obj -n "SPRITES" -f DIS/FIX80 my $asm = $ARGV[0]; my $home = `pwd`; chomp($home); my $path = "$home"; my $disk = "../work.dsk"; my ($object) = $asm =~ [email protected](.*?)\..*@gi; if (defined $object) { my $compiler = "$path/xas99.py -OR $asm"; my $objectFile = "$path/$object.obj"; print "$compiler\n"; my $retVal = system($compiler); if ($retVal == 0) { if (-e $objectFile) { my $name = uc($object); my $createDisk = "$path/xdm99.py $disk -a $objectFile -n \"$name\" -f DIS/FIX80"; print "$createDisk\n"; $retVal = system($createDisk); if ($retVal == 0) { print "\n$objectFile added to $disk\n"; } else { print "\ncould not add $objectFile to $disk\n"; } } else { print "\n$objectFile not found\n"; } } else { print "\n$asm did not compile\n"; } }
Usage: put scipt in your ~/bin. Run in dir with your xdt scripts & asm file
$ xdt.pl hidraw.asm
Really great set of tools!!
cheers
Daryn
-
Am really loving xdt99!
Been using it with the examples in the Lottrup assembly language book.
Every single example I've entered in using vim on my Linux box, have compiled, then Load and Run the object file with mini-memory in classic99 & now js99er has worked!
Attached is a hires draw asm example.
Here is a wee perl script wrapper I've written around xas99.py and xdm99.py to compile an object from an asm file, then add it to a DSK image (1 dir up).
name: xdt.pl
#!/usr/bin/perl use strict; use warnings; use Data::Dumper; # ./xas99.py -OR sprites.asm # ./xdm99.py work.dsk -a sprites.obj -n "SPRITES" -f DIS/FIX80 my $asm = $ARGV[0]; my $home = `pwd`; chomp($home); my $path = "$home"; my $disk = "../work.dsk"; my ($object) = $asm =~ [email protected](.*?)\..*@gi; if (defined $object) { my $compiler = "$path/xas99.py -OR $asm"; my $objectFile = "$path/$object.obj"; print "$compiler\n"; my $retVal = system($compiler); if ($retVal == 0) { if (-e $objectFile) { my $name = uc($object); my $createDisk = "$path/xdm99.py $disk -a $objectFile -n \"$name\" -f DIS/FIX80"; print "$createDisk\n"; $retVal = system($createDisk); if ($retVal == 0) { print "\n$objectFile added to $disk\n"; } else { print "\ncould not add $objectFile to $disk\n"; } } else { print "\n$objectFile not found\n"; } } else { print "\n$asm did not compile\n"; } }
Usage: put scipt in your ~/bin. Run in dir with your xdt scripts & asm file
$ xdt.pl hidraw.asm
Really great set of tools!!
cheers
Daryn
-
Sure you can. What are you having problems with, the loading of the disk image or the loading of the object file?
If you have Google Drive you can also use that option, this is like the FIAD option in Classic99, see post #145.
Hi Rasmus!
Nevermind, just got it to work! WOO!
I just did this post here explaining what i did using classic99 & mini-memory
Was able to repeat it just now. It was quite late last night when I tried it on js99er. Must have been too sleepy!
Cheers!
Daryn
-
Hi
I had a go using the xdt99 cross assembly under Linux trying out the example bit of code from the April 83 article in the 99ner mag titled "Programming Sprites in Mini Memory - Am assembly language tutorial" by Patricia Swift.
Download the attached "sprites.asm".
Compile into an object file by running this
$ ./xas99.py -OR sprites.asm
With the resulting "sprites.obj", in classic99 with the mini-memory module loaded, put the "sprites.obj" in a DSK folder, Choose "3. Mini Memory" from the menu, then Load and Run "DSK1.SPRITES.OBJ".
From there, exit out to EasyBug, then choose 'E', then 'E7D5C'
You should see some sprites moving around the screen.
Have attached the assembly code to use.
I really like xdt99, makes it alot easier to try examples!
cheers
Daryn
-
Hi
Have seen a mini-memory game called "Defend the Cities II" advertised/reviewed in the 99ner magazine. Also the author of the game (Jerry Spacek) wrote an article in the same magazine explaining the process he took in converting the original game from XB to assembly & the mini-memory module.
Does anyone have this game? It seems to have completely disappeared! It would be shame, as there were stuff all mini-memory games developed.
cheers
Daryn
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
US TI-99/4a & Commodore 1702 monitor
in TI-99/4A Computers
Posted
Cheers Ksarul, will do some digging on my 1702. Am sure it is a PAL one. Sounds like this might not be as easy as first thought
cheers
Daryn