TI-99/4A development resources

[Davvel]

I slacked off on restoring my download database, sorry. I'll get to that this weekend.

 

In the meantime, sort of. The VGM protocol itself does support timing of any sort, so it can handle sampled speech, but my playback code runs on the 60hz interrupt, which doesn't offer enough resolution for sample playback.

 

The TI is capable, of course. You wouldn't want to use VGM, as it uses multiple bytes per sample - raw data would be far more memory efficient.

Tursi, Thanks for your clear reply. I look forward to keep on studying all of the work carried out by you lot. I am dedicating approx. 3 hours a day going through Assembly and GPL. It is hard but I know the more I practice/read the more I will become accustomed to it and start getting rewarded through small achievements. I hope that one day I will be a net contributor like the great people that post in these forums.

[Davvel]

Can anyone help me out please. I am trying to reduce jitter whilst smooth scrolling using GPL. I am not doing anything special I am doing this to learn GPL not for a specific goal. I thought that if I would wait for the vertical sync before changing the pattern table the screen would look pretty solid but to my dismay it seems it does not do any difference when I remove the below code. I will be using double buffering if I want any serious solid smooth scrolling but I thought that I could save on some precious memory if I avoid double buffering for uncomplicated stuff which can happen between redraw of the screen.

 

VSYNC CLOG >80, >8802
BR VSYNC

[Tursi]

Unfortunately, that won't be reliable because the GPL interpreter enables VDP interrupts between every instruction, so direct polling of the status register will be inconsistent at best. It is, however, copied to address >837B, so you can poll it there.

 

I'm not sure how much luck you'll have, whether there's enough time in the vblank to handle frame sync from GPL, but it will be interesting to hear if it works!

[Davvel]

Tursi,

 

I had a small mistake as the COND flag is like inverse in my mind. COND is set when all bits GS AND GD return a zero. Given that GS=>80 then COND will be RESET only when VDPSTATUS bit 0 is 1 (Vertical Sync reached).

 

So I changed the code to

 

VSYNC CLOG >80, >8802
BS VSYNC (Note the BS not BR)

 

Which kind of worked but as you correctly predicted, the result is not reliable. I have smooth scrolling but sometimes it pauses as it misses a Sync or more. When I am lucky that the tight loop hits the vertical sync then the code resumes and scrolling is very solid.

 

I will now try double buffer.

[+Lee Stewart]

Is the GPL assembler smart enough to provide the missing '@' for the dest operand?

 

VSYNC CLOG >80, @>8802

 

If not, COND will always be reset if the operation is interpreted as “>80 AND >88” and always set if “>80 AND >02”.

 

...lee

[Davvel]

Lee,

 

It is a typo when I transferred the code into this forum, I have the @ sign in front of the variable I am using (sorry) It is @VS in my code where VS is >8802 but I thought I should convert it for clarity and forgot to type the @.

 

Thanks.

 

David

[Tursi]

Tursi,

 

I had a small mistake as the COND flag is like inverse in my mind. COND is set when all bits GS AND GD return a zero. Given that GS=>80 then COND will be RESET only when VDPSTATUS bit 0 is 1 (Vertical Sync reached).

 

So I changed the code to

 

VSYNC CLOG >80, >8802

BS VSYNC (Note the BS not BR)

 

Which kind of worked but as you correctly predicted, the result is not reliable. I have smooth scrolling but sometimes it pauses as it misses a Sync or more. When I am lucky that the tight loop hits the vertical sync then the code resumes and scrolling is very solid.

 

I will now try double buffer.

 

You should be able to do the exact same loop, but reading from CPU address >837B instead of >8800, and have a stable loop with no misses Even better, you will still be able to use the console interrupt routine for sprites and sound, if you wish to. It always stores the VDP status at that address when it reads it to clear the interrupt.

[Davvel]

 

You should be able to do the exact same loop, but reading from CPU address >837B instead of >8800, and have a stable loop with no misses Even better, you will still be able to use the console interrupt routine for sprites and sound, if you wish to. It always stores the VDP status at that address when it reads it to clear the interrupt.

Tursi,

 

Would you say that this should work ?

 

VSYNC CLOG >80, @>837B

BS VSYNC

 

In my case it seems that >837B never has bit 0 set or else I am doing the BIT compare incorrectly. When I used >8802 I had some improvement but not suitable for games as it is not reliable.

 

Who do you think is the best to ask about GPL in AtariAge ?

[Davvel]

Double buffer worked best, but I am trying a very simple scroll. Just 1 character repeated all over the screen and scrolled through a simple shift, I know that when I start complicating things and adding more characters GPL might start crawling. I did not double buffer the screen but the pattern table. From all this I learned some code which will surely come useful along the line.

Just if anyone is interested I am uploading this weekends effort.

demo8G.bin

To open use Classic99 Cartridge->User->Open

[+Ksarul]

You should probably start a separate GPL development thread. A lot of interesting fun is coming out of this discussion. Rich and Tursi are definitely the GPL experts--and both of them will definitely give you some useful tips.

[Davvel]

I will open a new development thread on GPL soon. My intention is that after I learn enough I will start sharing how I did whatever I worked on, but first back to reality, I need to learn myself as I might confuse others more than help at the moment. I do not consider myself a fast learner and might need to simmer for some time before anything good comes out I am still at ground 0 especially when compared to the massive work Tursi, Lee, Rasmus, Tony etc... who's masterpieces I admire.

[Tursi]

For GPL - Rich (RXB) far more than me, though. I've never even seen the CLOG instruction before, I've just hand-assembled a few simple programs.

[Tursi]

As for >837B no working for you, I have two thoughts. First is when I look in the debugger, I never see it NOT set. This actually makes sense because it's only copied out when the vertical interrupt has occurred, so it should always be set.

 

This suggests first that your bit compare is backwards, since it should have ALWAYS skipped right past, and secondly that for reliable results, you need to zero >837B after you detect the bit set (or at least clear bit >80). Otherwise you can't tell when the console sets it again.

 

Still, if you have double buffering to your liking, I wouldn't be too worried.

[Davvel]

Tursi, FYI after I posted I had changed my logic a little and as you said it was passing past the VSYNC logic as 837B never changed with BIT 0 always ON. What I did not try is clearing >837B, I assumed it will get cleared by the system but I will later try to clear it myself and see what happens.

 

As for double buffering, it is wonderful and has many possibilities which I am willing to use if I ever write a game even though I know it is expensive on memory.

 

To explain how CLOG works : CLOG GD,GS . This instruction sets COND "gpl status flag" when all bits are compared between GS and GD and all comparisons return a Zero (applies an AND operation between the bits). Therefore when testing >80 to VSYNC, we will be setting COND to 1 as long as Bit 0 (weight >80) = 0. When Bit 0 = 1 then COND = 0. It is inverted and makes your brain ache as you will use BS not BR to wait for COND=0

 

Thanks for you kind interest and help.

[Davvel]

You should probably start a separate GPL development thread. A lot of interesting fun is coming out of this discussion. Rich and Tursi are definitely the GPL experts--and both of them will definitely give you some useful tips.

 

Thread created: "GPL Development"

[Tursi]

Tursi, FYI after I posted I had changed my logic a little and as you said it was passing past the VSYNC logic as 837B never changed with BIT 0 always ON. What I did not try is clearing >837B, I assumed it will get cleared by the system but I will later try to clear it myself and see what happens.

No, it's a cached copy of the status register -- there's nothing in the system that clears it (and not much that reads it).

[+jedimatt42]

I understand there is a DEBUG program for debugging on the TI? I've been looking/searching around, but have had no luck. Anyone have a link?

 

-M@

[+Schmitzi]

please don´t ask me what this all is, I only make some lists :

 

(Debug) (GPL)

 

[+jedimatt42]

Thanks, that might help... I'm probably looking for Navarone Super Bugger. maybe...

[+Schmitzi]

.

I found some bugs on my harddisk

 

 

BUGs-rms01.zip

 

 

 

 

 

 

[+Vorticon]

Thanks, that might help... I'm probably looking for Navarone Super Bugger. maybe...

 

I believe the original debugger was found on one of the E/A disks. I use Superbug when I need to debug on real hardware as it has much better features. Frankly however, it is still a beast to use, so unless you are working on real iron (interfacing project for example), you are much better off using the Classic99 debugger under emulation.

I will try to post a disk image of Superbug later today.

[RXB]

What about posting the GPL Device Interface Manual?

 

It explains how GPL manipulates CRU bits and does a much better job of interface with Devices then Assembly can do.

[+Ksarul]

Do we have a good scan of that one, Rich?

 

I do have one additional useful document to put up: the source code for the BASIC Support module. I finished typing in the last of it this week so that we now have a really nice crisp copy in addition to the scan I put up on WHT a few years ago.

TI BASIC Support Module (Restored).pdf

[marc.hull]

What about posting the GPL Device Interface Manual?

 

It explains how GPL manipulates CRU bits and does a much better job of interface with Devices then Assembly can do.

OK, I'll bite. How can GPL interface with devices better than assembly ?

[kl99]

What about posting the GPL Device Interface Manual?

 

It explains how GPL manipulates CRU bits and does a much better job of interface with Devices then Assembly can do.

 

Is this a dedicated manual by TI or do you mean the known GPL Programmer's Guide? I would be very interested to read such a manual.