Author Topic: porting old prgms  (Read 11092 times)

0 Members and 1 Guest are viewing this topic.

Offline dreamdragon

  • LV3 Member (Next: 100)
  • ***
  • Posts: 72
  • Rating: +6/-19
  • Dragon born and Dragon raised.
    • View Profile
Re: porting old prgms
« Reply #15 on: January 15, 2014, 09:48:26 am »
Portal Prelude was in Axe Parser, not BASIC. As long as Axe isn't ported to the CSE, I doubt that anyone will bother porting Portal Prelude, unless someone is really willing to make a Z80 ASM version from scratch.

Also your posts seems like you are trying to force other people to port programs you want. It is disrespectful. We have lives besides Omnimaga and calculators and we will only port programs if we are willing to do so. Same goes for Axe Parser CSE: The author will only make it if he is willing to do so or if he has time to. If you really want Portal to be available on the 84+CSE this soon, quit using us as your slaves and do it yourself.

sorry. i got a little bit too excited. :'( :-[
how do i port, if i might kindly ask. ::)

Offline dreamdragon

  • LV3 Member (Next: 100)
  • ***
  • Posts: 72
  • Rating: +6/-19
  • Dragon born and Dragon raised.
    • View Profile
Re: porting old prgms
« Reply #16 on: January 15, 2014, 09:14:54 pm »
I'd like to point out how much leeway the forumers have been giving you, dreamdragon. :)

A major problem (besides those listed already) is that many games already pushed the limits of the calc itself and were well written for THAT hardware. This calc is very different and also takes MUCH longer to do screen-related things, which is most of what makes these games: fancy graphics.


Also, many old coders who wrote stuff like Phoenix a decade ago don't stick around anymore to help put stuff on the CSE.

ouchies...first word to the old programmers leavin ya guys.....
im so ni eve ...
i will try to be more mature...

Offline Lunar Fire

  • LV3 Member (Next: 100)
  • ***
  • Posts: 66
  • Rating: +7/-1
  • I'll be watching you from the shadows
    • View Profile
    • My Tumblr
Re: porting old prgms
« Reply #17 on: January 15, 2014, 10:04:00 pm »
It is not easy to port game to the TI-84+CSE. First, because programs on the TI-84 are not optimized for this model. Second, because the CSE is not graphically optimal.

The CSE has too few RAM and CPU speed to run smooth games like the non-CSE model did. It is a limitation because even if the programmers keep the sprites in B/W, the CSE still has to render them like color sprites, therefore making games slower than they could run on their original hardware.

That limits the applications that can be ported to the CSE for now. It is not impossible for TI to release a better CSE in the future, but for now games like Portal Prelude or F-Zero probably won't be ported.

As for how to port games, it is the process of re-writing the source code with the new hardware in mind. Luckily, the B/W and CSE models use the same processor architecture (no need to use a new ASM language), but a few things might have changed, like the location of interrupts, system calls and most obvious of all, display functions.

In this perspective, I wonder if a how-to guide for porting game from the B/W models to the CSE is possible. A reference document where the changes between these and how they affect the code are documented. Maybe a post here on Omni like the Axe Parser threads.
« Last Edit: January 16, 2014, 12:36:36 pm by LunarFire »
Your drill is the drill that will pierce the heavens!

Offline The_King

  • LV5 Advanced (Next: 300)
  • *****
  • Posts: 247
  • Rating: +6/-2
  • Ⓣⓗⓔ Ⓖⓐⓜⓔ ⓍⒹ
    • View Profile
Re: porting old prgms
« Reply #18 on: January 15, 2014, 10:07:33 pm »
Quote
It is not impossible for TI to release a better CSE in the future, but for now games like Portal Prelude or F-Zero probably won't be ported.

however if TI wanted it could have released at least a CSE with similar specs to other calcs but it is locking down CSE like it did on nspires

Offline Hayleia

  • Programming Absol
  • Coder Of Tomorrow
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3367
  • Rating: +393/-7
    • View Profile
Re: porting old prgms
« Reply #19 on: January 16, 2014, 02:06:54 am »
The CSE has too few RAM and CPU speed to run smooth games like the TI-84 did. It is a limitation because even if the programmers keep the sprites in B/W, the CSE still has to render them like color sprites, therefore making games slower than they could run on their original hardware.

That limits the applications that can be ported to the CSE for now. It is not impossible for TI to release a better CSE in the future, but for now games like Portal Prelude or F-Zero probably won't be ported.
IIRC, the CSE has more RAM than newer 84+ calcs due to extra RAM pages being back. And it doesn't have a higher CPU speed, but since Portal Prelude was made in 6MHz to keep compatibility with the regular 83+, you can still think you do have a higher CPU speed available. You also have the possibility not to refresh the whole screen, which can work on a "static" game like Portal Prelude. But yeah, F-Zero is going to be harder.

the TI-84.
I always say that, and I seem to be the only one, but there is no "the TI-84". This because there is always something behind the "84", either a "Plus" or a "Pocket", sometimes both, sometimes followed by a ".fr" or a "SE", and now with the possibility of a "CSE". So yeah, I can understand that you can't name them all each time and that most of them are compatible between each other, but now that the CSE is out (and since you mentionned the CSE in your sentence), you could talk about non-CSE 84 calcs as "the non-CSE 84 calcs", but not "the 84" since even in your sentence you are talking about another 84 calc so really, there is no "the 84".

the Arse Parser threads.
*.*
Heresy! :P
« Last Edit: January 16, 2014, 02:09:18 am by Hayleia »
I own: 83+ ; 84+SE ; 76.fr ; CX CAS ; Prizm ; 84+CSE
Sorry if I answer with something that seems unrelated, English is not my primary language and I might not have understood well. Sorry if I make English mistakes too.

click here to know where you got your last +1s

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55943
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Re: Re: porting old prgms
« Reply #20 on: January 16, 2014, 07:12:57 am »
Smooth games are possible on the CSE as long as you don't refresh huge parts of the LCD memory every frame. See Tunnel.8xk, Jumper, JezzBall, Tetrica and Pac-Man, for example. Therefore, Portal Prelude would be possible.

Offline dreamdragon

  • LV3 Member (Next: 100)
  • ***
  • Posts: 72
  • Rating: +6/-19
  • Dragon born and Dragon raised.
    • View Profile
Re: Re: porting old prgms
« Reply #21 on: January 16, 2014, 08:09:58 am »
Smooth games are possible on the CSE as long as you don't refresh huge parts of the LCD memory every frame. See Tunnel.8xk, Jumper, JezzBall, Tetrica and Pac-Man, for example. Therefore, Portal Prelude would be possible.

agreed. i downloaded tunnel,jumper,jezz ball, tetrica and pacman. ;D
they run awesome with absolutely no lag what so ever. ;)
if i do port, i would have to look for the similarities for the basic codes between the two calcs, yes?  :)
however.... :-[
the science programs like periodic take forever to draw themselves... :banghead:
(ps: who is assm bandit???) ???

Quote
It is not impossible for TI to release a better CSE in the future, but for now games like Portal Prelude or F-Zero probably won't be ported.

however if TI wanted it could have released at least a CSE with similar specs to other calcs but it is locking down CSE like it did on nspires
what do you mean locking? :-\
yes there are new codes in the basic library than the other 84s, but i would not say locking. <_<
n spire is n spire! :evillaugh:

EDIT: Post merged- Xeda112358
« Last Edit: January 16, 2014, 12:59:07 pm by Xeda112358 »

Offline Hayleia

  • Programming Absol
  • Coder Of Tomorrow
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3367
  • Rating: +393/-7
    • View Profile
Re: porting old prgms
« Reply #22 on: January 16, 2014, 09:32:42 am »
Locking as in "no native programming support".
I own: 83+ ; 84+SE ; 76.fr ; CX CAS ; Prizm ; 84+CSE
Sorry if I answer with something that seems unrelated, English is not my primary language and I might not have understood well. Sorry if I make English mistakes too.

click here to know where you got your last +1s

Offline Lunar Fire

  • LV3 Member (Next: 100)
  • ***
  • Posts: 66
  • Rating: +7/-1
  • I'll be watching you from the shadows
    • View Profile
    • My Tumblr
Re: porting old prgms
« Reply #23 on: January 16, 2014, 12:38:48 pm »
the Arse Parser threads.
*.*
Heresy! :P

Oopsies, fixed. Also fixed the TI-84 reference.
Your drill is the drill that will pierce the heavens!

Offline Xeda112358

  • they/them
  • Moderator
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 4704
  • Rating: +719/-6
  • Calc-u-lator, do doo doo do do do.
    • View Profile
Re: porting old prgms
« Reply #24 on: January 16, 2014, 01:23:54 pm »
In assembly, sprite rendering would be faster for most size, but only if you have a handful of sprites. Basically, you save time by being able to draw directly to the LCD at pixel coordinates without an LCD delay.

Also, dreamdragon, it is preferred that you use the "Quick Modify" or "Modify" buttons to edit your post instead of posting close together (also known as a "double post" which is referred to in the rules).

Offline chickendude

  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 817
  • Rating: +90/-1
  • Pro-Riot Squad
    • View Profile
Re: porting old prgms
« Reply #25 on: January 16, 2014, 01:32:06 pm »
Is drawing 8 pixels individually really faster than a write to the gbuf and to the lcd?

EDIT: i guess for non-aligned sprites, it probably is.
« Last Edit: January 16, 2014, 01:32:51 pm by chickendude »

Offline Xeda112358

  • they/them
  • Moderator
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 4704
  • Rating: +719/-6
  • Calc-u-lator, do doo doo do do do.
    • View Profile
Re: porting old prgms
« Reply #26 on: January 16, 2014, 01:46:42 pm »
For that size, no. However, a 16-bit color, 16x16 sprite at arbitrary coordinates (no clipping) would take 9506 t-states. On the monochrome models, you would have to rotate the sprite data accordingly before drawing to the gbuf, and then you would have to update possibly 3 columns of 16 pixels tall.

I think I can manage the drawing part using SMC in about 5400 t-states, then the LCD update part would require some quick overhead code to compute the offset into the gbuf, 6 coordinate writes to the LCD, and 48 data writes totaling 54 writes. Assuming the rest of the code is handled in the wait-states, if the average wait-states are 76, then the color model is only slightly faster.

So at 6MHz, it is faster on the monochrome calcs in most cases. However, the monochrome calc wouldn't be running at 6MHz, it would be 15MHz which could require about 130 cycles between LCD writes (sometimes more, sometimes less). In this case, it would take >12000 t-states.

EDIT: For reference, here is the (possibly incorrect) code I was referring to for the CSE calculations:
Code: [Select]
    ld hl,$10B8        ; BGR mode, increment order
    ld a,$03
    call SetLCDRegister

    call SetSpriteWindow
    ld hl,sprite
    call RenderSprite
<< do whatever >>
    ret

RenderSprite:
;Input:
;  HL points to the sprite
    ld bc,17
    ld d,2
outi \ outi \ outi \ outi
outi \ outi \ outi \ outi
jp nz,$-16
dec d
jr nz,$-20
    ret

SetSpriteWindow:
    ld de,15
    ld a,$50

    ld hl,(y_coord)
    call SetLCDRegister        ;Horizontal Start
    add hl,de
    call SetLCDReg        ;Horizontal End

    ld hl,(x_coord)
    call SetLCDReg        ;Vertical Start
    add hl,de
    call SetLCDReg        ;Vertical End

    ld hl,(y_coord)
    ld a,$20
    call SetLCDReg        ;Y pos
    ld hl,(x_coord)
    call SetLCDReg        ;X pos
SetLCDRegister:
    ld c,$11
SetLCDReg:
    out ($10),a \ out ($10),a
    out (c),h
    out (c),l
    inc a
    ret

sprite:
    .db $03,$C0,$0D,$70,$10,$A8,$20,$54,$40,$2A,$40,$16,$80,$2B,$80,$15
    .db $80,$2B,$40,$56,$30,$AC,$0E,$70,$01,$80,$01,$80,$03,$C0,$07,$E0
x_coord:
    .dw 151
y_coord:
    .dw 112
I adapted it from my attempt at writing a monochrome sprite routine, so the sprite data is mostly garbage now :P

Offline dreamdragon

  • LV3 Member (Next: 100)
  • ***
  • Posts: 72
  • Rating: +6/-19
  • Dragon born and Dragon raised.
    • View Profile
Re: porting old prgms
« Reply #27 on: January 16, 2014, 04:51:54 pm »
In assembly, sprite rendering would be faster for most size, but only if you have a handful of sprites. Basically, you save time by being able to draw directly to the LCD at pixel coordinates without an LCD delay.

Also, dreamdragon, it is preferred that you use the "Quick Modify" or "Modify" buttons to edit your post instead of posting close together (also known as a "double post" which is referred to in the rules).
opps :-[

Offline rot3

  • LV0 Newcomer (Next: 5)
  • Posts: 2
  • Rating: +0/-0
    • View Profile
Re: porting old prgms
« Reply #28 on: February 02, 2014, 11:02:35 pm »
I just got the the new +c. Not a lot of games but the ones like jumper are fun.

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55943
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Re: porting old prgms
« Reply #29 on: February 02, 2014, 11:13:21 pm »
Heya and welcome to the forums by the way. :D

I hope to make some more +C games myself, but motivation is hard to get at the right moment x.x