Assembly under emulation

[ceratophyllum]

Waaay back near the beginning of this thread I posted the CALL KEY example

from Beginning Assembly. I was meaning to ask:

 

5,3,0,2 are not the ASCII values for E,S,D,X....

but the program works right.

I don't know what these numbers mean.

(I was suspicious of a typo since the book has

a few.)

 

What is going on here?

 

The first line means label an address KEYUP and stick

a 5 in there, right?

 

*
KEYUP BYTE 5                 *             ASCII values
KEYRT BYTE 3                 *           of E, D, X and S
KEYDN BYTE 0                 *               keys
KEYLT BYTE 2                 *
HEXFF BYTE >FF               * No key pressed value
ONE   BYTE 1                 *
*

[matthew180]

What are you using for an editor? Also, make sure you have some syntax highlighting set up. It makes a difference!

I settled on Notepad++. Makes the source much more readable. I could get used to this

 

Yup. Once you have syntax highlighting, you don't go back. It is more than just "pretty", it helps prevent bugs because if you spell something wrong, it does not color, and you realize the problem right away. Unfortunately there are no intelligent editors for 9900 assembly (like Eclipse does for C, Java, etc.), but just the coloring helps a lot. I'm pretty sure someone did a 9900 assembly syntax file for Notepad++.

[matthew180]

5,3,0,2 are not the ASCII values for E,S,D,X....

but the program works right.

I don't know what these numbers mean.

(I was suspicious of a typo since the book has

a few.)

 

What is going on here?

 

Have a look on page 201 of the XB manual. Those are the "split keyboard" return values. Since you are using the console keyscan routine instead of directly scanning the keyboard, those are the numbers you have to use.

[Willsy]

Someone made a syntax highlighting file for Notepad++, didn't they?

 

I still haven't got into that. But maybe I could.

 

The bug in Asm994a was that one of the jump instructions (JH?) assembled to a different kind of jump. So it was a pretty important one!

 

Yeah, it was me originally. Philip modified it slightly and made it available on his site IIRC.

 

Here's a screen shot:

FWIW: I've been using the ASM994A Assembler for about 3 years. TurboForth consists of 40 (yes, 40!) assembly files, and assembles in approx 2 seconds on my machine.

 

I have a batch file which takes the object code, and creates ROM files for Classic99, MESS and TI994W in a single batch file!

 

The syntax highlighting and code folding is very useful in Notepad++

[+Vorticon]

I've been only using Notepad++ for a few days and it's going to be very hard to go back to standard text editing on the TI Coming from me, it sounds like heresy!

[matthew180]

There is nothing wrong with liking modern tools. Back in the day, we did what we could, but computers advanced and so did the tools. Denying the modern stuff out of "purism" is just unjustified stubbornness IMO. I always wanted better graphics from my 99/4A, but it only has 16 colors and a fixed resolution, however I don't condemn my PC from having 24-bit color.

 

There is a lot about the 99/4A that was a pain in the ass to do on the console, especially the assembly development cycle. And the keyboard (all the keyboards on the early 80's "home computers") is not adequate for programming, again IMO.

 

I like hacking on my real gear every now and then just for the fun of it, but for any code more than a few lines, I'll do it on the PC and test with emulation. Once it is all working, then test it on the metal. Since this is a hobby for me (and most everyone), the time spent waiting for floppy disks, assemblers, loading, saving, etc. is just wasted time.

[+Vorticon]

There is nothing wrong with liking modern tools. Back in the day, we did what we could, but computers advanced and so did the tools. Denying the modern stuff out of "purism" is just unjustified stubbornness IMO. I always wanted better graphics from my 99/4A, but it only has 16 colors and a fixed resolution, however I don't condemn my PC from having 24-bit color.

 

There is a lot about the 99/4A that was a pain in the ass to do on the console, especially the assembly development cycle. And the keyboard (all the keyboards on the early 80's "home computers") is not adequate for programming, again IMO.

 

I like hacking on my real gear every now and then just for the fun of it, but for any code more than a few lines, I'll do it on the PC and test with emulation. Once it is all working, then test it on the metal. Since this is a hobby for me (and most everyone), the time spent waiting for floppy disks, assemblers, loading, saving, etc. is just wasted time.

You're probably right. Nonetheless, there is something vaguely manly about programming an entire project on the real thing Truth be told though, this is only practical for Basic/XB, and possibly C99 and P-code projects. I don't know about Turbo Forth yet. But when it comes to large assembly projects, emulation is likely necessary unless one has reliable equipment and lots of time, both of which are in short supply these days I switched my Skychart project half-way through to emulation after spending 15-20 minutes for each compilation cycle to complete on real hardware, and now Ultimate Planet is also living in emulation for the same reason as well as hardware issues.

 

As long as the finished project runs on the real thing, then that's what counts after all...

[ceratophyllum]

Someone made a syntax highlighting file for Notepad++, didn't they?

 

I still haven't got into that. But maybe I could.

 

The bug in Asm994a was that one of the jump instructions (JH?) assembled to a different kind of jump. So it was a pretty important one!

 

Yeah, it was me originally. Philip modified it slightly and made it available on his site IIRC.

 

Here's a screen shot:

FWIW: I've been using the ASM994A Assembler for about 3 years. TurboForth consists of 40 (yes, 40!) assembly files, and assembles in approx 2 seconds on my machine.

 

I have a batch file which takes the object code, and creates ROM files for Classic99, MESS and TI994W in a single batch file!

 

The syntax highlighting and code folding is very useful in Notepad++

 

 

How are you getting those nifty colors and folding?

I tried a few pre-installed highlighting modes,

but none of them looked so great. Could you post the

config file or explain what you did?

 

Wait a minute. Where's Philip's site?

 

I still use cruddy old vi because it never goes away and fails

to bewilder me like emacs does. (It comes preinstalled or

easily apt-gotten, rpm-ed, etc. on just about every

unix on earth.)

[marc.hull]

 

You're probably right. Nonetheless, there is something vaguely manly about programming an entire project on the real thing Truth be told though, this is only practical for Basic/XB, and possibly C99 and P-code projects. I don't know about Turbo Forth yet. But when it comes to large assembly projects, emulation is likely necessary unless one has reliable equipment and lots of time, both of which are in short supply these days I switched my Skychart project half-way through to emulation after spending 15-20 minutes for each compilation cycle to complete on real hardware, and now Ultimate Planet is also living in emulation for the same reason as well as hardware issues.

 

As long as the finished project runs on the real thing, then that's what counts after all...

 

 

Hmmmmm.....The manley man programmers club ??? Where can I get a T-shirt ?

 

I don't doubt that it is true that emulation is faster and easier but since it is a hobby whats a few extra minutes ? Slow down and enjoy the scenery ? Personally I don't see it as wasted time at all.

 

BTW, My last assembly project was around 300K of DV-80 and from saving the source, assembling and running the object is less than 5 minutes provided you are using the right tools. Reliability can be an issue but it just adds one more adventure to the hobby (if your so inclined.)

 

Hopefully you don't totally abandon your console work. The manley men club waits for your return

[Willsy]

Someone made a syntax highlighting file for Notepad++, didn't they?

 

I still haven't got into that. But maybe I could.

 

The bug in Asm994a was that one of the jump instructions (JH?) assembled to a different kind of jump. So it was a pretty important one!

 

Yeah, it was me originally. Philip modified it slightly and made it available on his site IIRC.

 

Here's a screen shot:

FWIW: I've been using the ASM994A Assembler for about 3 years. TurboForth consists of 40 (yes, 40!) assembly files, and assembles in approx 2 seconds on my machine.

 

I have a batch file which takes the object code, and creates ROM files for Classic99, MESS and TI994W in a single batch file!

 

The syntax highlighting and code folding is very useful in Notepad++

 

 

How are you getting those nifty colors and folding?

I tried a few pre-installed highlighting modes,

but none of them looked so great. Could you post the

config file or explain what you did?

 

Wait a minute. Where's Philip's site?

 

I still use cruddy old vi because it never goes away and fails

to bewilder me like emacs does. (It comes preinstalled or

easily apt-gotten, rpm-ed, etc. on just about every

unix on earth.)

 

You'll find it here:

http://www.atariage.com/forums/topic/153704-ti-994a-development-resources/page__p__1939461#entry1939461

 

Also, check out the Retroclouds website which has installation instructions.

[+Vorticon]

 

You're probably right. Nonetheless, there is something vaguely manly about programming an entire project on the real thing Truth be told though, this is only practical for Basic/XB, and possibly C99 and P-code projects. I don't know about Turbo Forth yet. But when it comes to large assembly projects, emulation is likely necessary unless one has reliable equipment and lots of time, both of which are in short supply these days I switched my Skychart project half-way through to emulation after spending 15-20 minutes for each compilation cycle to complete on real hardware, and now Ultimate Planet is also living in emulation for the same reason as well as hardware issues.

 

As long as the finished project runs on the real thing, then that's what counts after all...

 

 

Hmmmmm.....The manley man programmers club ??? Where can I get a T-shirt ?

 

I don't doubt that it is true that emulation is faster and easier but since it is a hobby whats a few extra minutes ? Slow down and enjoy the scenery ? Personally I don't see it as wasted time at all.

 

BTW, My last assembly project was around 300K of DV-80 and from saving the source, assembling and running the object is less than 5 minutes provided you are using the right tools. Reliability can be an issue but it just adds one more adventure to the hobby (if your so inclined.)

 

Hopefully you don't totally abandon your console work. The manley men club waits for your return

300K of source assembled in less than 5 minutes??? No freaking way! What kind of tools are you using? If I was able to replicate this kind of speed, I would stand on top of my PEB and beat my chest in triumph

[marc.hull]

 

You're probably right. Nonetheless, there is something vaguely manly about programming an entire project on the real thing Truth be told though, this is only practical for Basic/XB, and possibly C99 and P-code projects. I don't know about Turbo Forth yet. But when it comes to large assembly projects, emulation is likely necessary unless one has reliable equipment and lots of time, both of which are in short supply these days I switched my Skychart project half-way through to emulation after spending 15-20 minutes for each compilation cycle to complete on real hardware, and now Ultimate Planet is also living in emulation for the same reason as well as hardware issues.

 

As long as the finished project runs on the real thing, then that's what counts after all...

 

 

Hmmmmm.....The manley man programmers club ??? Where can I get a T-shirt ?

 

I don't doubt that it is true that emulation is faster and easier but since it is a hobby whats a few extra minutes ? Slow down and enjoy the scenery ? Personally I don't see it as wasted time at all.

 

BTW, My last assembly project was around 300K of DV-80 and from saving the source, assembling and running the object is less than 5 minutes provided you are using the right tools. Reliability can be an issue but it just adds one more adventure to the hobby (if your so inclined.)

 

Hopefully you don't totally abandon your console work. The manley men club waits for your return

300K of source assembled in less than 5 minutes??? No freaking way! What kind of tools are you using? If I was able to replicate this kind of speed, I would stand on top of my PEB and beat my chest in triumph

 

Fast crystal, Fast memory RAM disk and funnelweb......

[+Vorticon]

I think I found another issue with ASM99a: The following sequence (to generate an error tone) corrupts the screen...

CLR     R1
MOVB R1,@GPLSTS    GPLSTS DEFINED AS >837C
BLWP @GPLLNK
DATA >0036

This is likely related to GPLLNK, unless I'm missing something.

[+Vorticon]

Fast crystal, Fast memory RAM disk and funnelweb......

The faster crystal is supposed to give you at most a 20% increase in speed. I suppose when combined with the RAM disk, then it could account for your performance gains... Still, I like the fact that I can have my entire source code all in a single file instead of having to break it into smaller sections which is very cumbersome when it comes to editing and hunting down bugs.

Who knows, if ASM99a keeps popping up with bugs then I may have to revert back to the old ways

[Willsy]

The faster crystal is supposed to give you at most a 20% increase in speed. I suppose when combined with the RAM disk, then it could account for your performance gains... Still, I like the fact that I can have my entire source code all in a single file instead of having to break it into smaller sections which is very cumbersome when it comes to editing and hunting down bugs.

Who knows, if ASM99a keeps popping up with bugs then I may have to revert back to the old ways

 

Not when your assembly project totals 8,177 lines and counting

 

Then you will be very very glad for multi-file projects, believe me!

 

Mark

[+Vorticon]

I'm only still at 2074 lines, although I do expect to almost double that by the time the project is done. As to editing large files, one can hop around easily using the search function as long as you sections are labeled properly. It's faster than loading separate files, although there is definitely a chance of losing your entire work in one shot if your file become corrupted for some reason. I guess that's what backup is for

Don't misunderstand me, I am a die hard real hardware fan, but I have to agree with Matt that this should not preclude the use of modern tools when necessary.

8100+ lines!!! Is this the code for the SID card or is it some mystery project I have no knowledge of? You must be getting real close to your memory limits here, and I still have a hard time believing you can compile this is under a minute

[Willsy]

Is this the code for the SID card or is it some mystery project I have no knowledge of? You must be getting real close to your memory limits here, and I still have a hard time believing you can compile this is under a minute

 

Ah! No! That's Marc - I'm Mark. Confusing isn't it!

 

TurboForth is 8177 lines - checked this morning, and it's still (just) under 16K. Scary.

 

Splitting your code into multiple files (this is just my opinion, of course) is easier than searching through the file, though if it works for you, then that's fine!

 

Regarding assembling code on the TI, it is possible to massively reduce assembly time by using the TI Assembler the way it was meant to be used.

 

When we assemble on the TI, we tend to assemble the whole assembly project, from start to finish. This is a real pain if your project is large and you only want to change a single MOV to a MOVB

 

Of course, it doesn't have to be done that way at all - TI provided us with an assembler of unprecedented power when you compare it to the primitive assemblers available for the TI's peers of the day, which had *nothing* like what was available on the TI. The TI is a proper 'system' and is similar to it's TI Mini's in some ways. Anyway, I digress...

 

...if you split your code into multiple files, then, when you need to make a change, you only need to assemble the file in which you made your change. You don't need to assemble the others.

 

References to addresses etc between files is automatically handled for you by the assembler; you just need to REF them.

 

Years ago, when I wrote The Game Writers Toolkit, I originally wrote the code in a notebook and typed it into the line-by-line assembler in MiniMem! Later, when I got a disk system, I put each CALL LINK word into it's own source file. Then, if I need to change one word, I just assemble one file. If you want to re-assemble the entire project, you can have a 'top-level' assembly file, which just consists of COPY directives.

 

You probably know this already, just repeating this stuff for the die-hards

 

Mark

[marc.hull]

I'm only still at 2074 lines, although I do expect to almost double that by the time the project is done. As to editing large files, one can hop around easily using the search function as long as you sections are labeled properly. It's faster than loading separate files, although there is definitely a chance of losing your entire work in one shot if your file become corrupted for some reason. I guess that's what backup is for

Don't misunderstand me, I am a die hard real hardware fan, but I have to agree with Matt that this should not preclude the use of modern tools when necessary.

8100+ lines!!! Is this the code for the SID card or is it some mystery project I have no knowledge of? You must be getting real close to your memory limits here, and I still have a hard time believing you can compile this is under a minute

 

I think your mixing conversations (Mark and Marc) so for clarification (on my end anyway)....

 

Sid player 300K+ of source (which I must admit that at least 50 percent is comments so lets say 150K of code that gets worked on.) EA5 object is about 22K.

 

14.3 Mhz crystal adds like you said about A 16 percent speed gain. Combined with 32k on the full width buss and no wait states you get a console that is better than twice as fast (Tursi will have to comment on my claim here as I am not sure "twice" is correct.)

I have never had an issue with file access be it DSK. SCSI IDE or RAM disk at these speeds. RS232 and PIO access seem to also be unaffected despite other claims.

 

Add in a RAM disk and file manipulation is now negligible especially with a faster console. Ram disk obviously accounts for the greatest speed difference.

 

Using Funnelweb eliminates a bunch of typing which also adds in efficiency and eliminates finger errors.

 

The figure was under 5 minutes not under a minute but that would be really nice. I have seen the Geneve do the assembly in MDOS mode in under 30 seconds which was really cool !

 

Don't get me wrong I am a live and let live guy. Real gear cool. Emulation cool. To each his own. Only responded because of the compare of the worst case of real gear to the best case of emulation in a previous post.

[Tursi]

14.3 Mhz crystal adds like you said about A 16 percent speed gain. Combined with 32k on the full width buss and no wait states you get a console that is better than twice as fast (Tursi will have to comment on my claim here as I am not sure "twice" is correct.)

 

hee, thanks for the thought, but I don't have the hard data to clarify, confirm, or refute that value.

[+Vorticon]

Is this the code for the SID card or is it some mystery project I have no knowledge of? You must be getting real close to your memory limits here, and I still have a hard time believing you can compile this is under a minute

 

Ah! No! That's Marc - I'm Mark. Confusing isn't it!

 

TurboForth is 8177 lines - checked this morning, and it's still (just) under 16K. Scary.

 

Splitting your code into multiple files (this is just my opinion, of course) is easier than searching through the file, though if it works for you, then that's fine!

 

Regarding assembling code on the TI, it is possible to massively reduce assembly time by using the TI Assembler the way it was meant to be used.

 

When we assemble on the TI, we tend to assemble the whole assembly project, from start to finish. This is a real pain if your project is large and you only want to change a single MOV to a MOVB

 

Of course, it doesn't have to be done that way at all - TI provided us with an assembler of unprecedented power when you compare it to the primitive assemblers available for the TI's peers of the day, which had *nothing* like what was available on the TI. The TI is a proper 'system' and is similar to it's TI Mini's in some ways. Anyway, I digress...

 

...if you split your code into multiple files, then, when you need to make a change, you only need to assemble the file in which you made your change. You don't need to assemble the others.

 

References to addresses etc between files is automatically handled for you by the assembler; you just need to REF them.

 

Years ago, when I wrote The Game Writers Toolkit, I originally wrote the code in a notebook and typed it into the line-by-line assembler in MiniMem! Later, when I got a disk system, I put each CALL LINK word into it's own source file. Then, if I need to change one word, I just assemble one file. If you want to re-assemble the entire project, you can have a 'top-level' assembly file, which just consists of COPY directives.

 

You probably know this already, just repeating this stuff for the die-hards

 

Mark

Sorry about the confusion here I was just about to take a plane and fly to OK to verify in person Marc's compilation claims!

I do use a master file with COPY directives, primarily because the TI editors cannot handle large source files. I honestly never tried to compile sections of the source, and I would appreciate it if you could elaborate on this a bit more. I understand REFing the utilities, but what about jumps and branches between different source files?

[+Vorticon]

I'm only still at 2074 lines, although I do expect to almost double that by the time the project is done. As to editing large files, one can hop around easily using the search function as long as you sections are labeled properly. It's faster than loading separate files, although there is definitely a chance of losing your entire work in one shot if your file become corrupted for some reason. I guess that's what backup is for

Don't misunderstand me, I am a die hard real hardware fan, but I have to agree with Matt that this should not preclude the use of modern tools when necessary.

8100+ lines!!! Is this the code for the SID card or is it some mystery project I have no knowledge of? You must be getting real close to your memory limits here, and I still have a hard time believing you can compile this is under a minute

 

I think your mixing conversations (Mark and Marc) so for clarification (on my end anyway)....

 

Sid player 300K+ of source (which I must admit that at least 50 percent is comments so lets say 150K of code that gets worked on.) EA5 object is about 22K.

 

14.3 Mhz crystal adds like you said about A 16 percent speed gain. Combined with 32k on the full width buss and no wait states you get a console that is better than twice as fast (Tursi will have to comment on my claim here as I am not sure "twice" is correct.)

I have never had an issue with file access be it DSK. SCSI IDE or RAM disk at these speeds. RS232 and PIO access seem to also be unaffected despite other claims.

 

Add in a RAM disk and file manipulation is now negligible especially with a faster console. Ram disk obviously accounts for the greatest speed difference.

 

Using Funnelweb eliminates a bunch of typing which also adds in efficiency and eliminates finger errors.

 

The figure was under 5 minutes not under a minute but that would be really nice. I have seen the Geneve do the assembly in MDOS mode in under 30 seconds which was really cool !

 

Don't get me wrong I am a live and let live guy. Real gear cool. Emulation cool. To each his own. Only responded because of the compare of the worst case of real gear to the best case of emulation in a previous post.

Thanks for the clarification I'm with you on hardware, but unfortunately with my current set up things are pretty inefficient for large projects. I do have the 32K internal RAM kit I got from Richard Bell (not installed yet), and I can probably also do the fast crystal modification as it is well documented on the Mainbyte site. I also have a 512K Corcomp RAM disk, but it seems to have reliability issues with FW. When I have some extra time, I'll see if I can beef up my console. You got me real motivated here!

[+Vorticon]

I think I found another issue with ASM99a: The following sequence (to generate an error tone) corrupts the screen...

CLR     R1
MOVB R1,@GPLSTS    GPLSTS DEFINED AS >837C
BLWP @GPLLNK
DATA >0036

This is likely related to GPLLNK, unless I'm missing something.

OK, it turned out that using END START instead of END somehow corrupts the GPLLNK utility. It took me a while to figure out why perfectly good code was misbehaving, until I remembered that I had a similar issue while coding the Chaos programs. I still don't have a clear explanation as to why this is the case, and I would love for someone here to enlighten me.

Another bit of advice: never, and I mean NEVER, compile large amounts of untested code in a single shot. I just spent several hours trying to unravel the mess I created with my latest code additions, with things blowing up right and left, and finally ended up deleting all the new stuff and then reentering it bit by bit while testing along the way. I think my code is too complex for its own good, with some routines having as many as 4 levels of nesting, making debugging a nightmare. Some hobby

[marc.hull]

 

Thanks for the clarification I'm with you on hardware, but unfortunately with my current set up things are pretty inefficient for large projects. I do have the 32K internal RAM kit I got from Richard Bell (not installed yet), and I can probably also do the fast crystal modification as it is well documented on the Mainbyte site. I also have a 512K Corcomp RAM disk, but it seems to have reliability issues with FW. When I have some extra time, I'll see if I can beef up my console. You got me real motivated here!

 

 

I used CorComp 512K for a while and found I had issues with using it a DSK1. It would do some funky things sometimes, mostly corrupt the source code with an odd character here or there. I stopped using it when I did the 32K mod. They are not compatible. If you are interested I do have a 1.5 MEG Horizon that is spare.

[+Vorticon]

 

I used CorComp 512K for a while and found I had issues with using it a DSK1. It would do some funky things sometimes, mostly corrupt the source code with an odd character here or there. I stopped using it when I did the 32K mod. They are not compatible. If you are interested I do have a 1.5 MEG Horizon that is spare.

That's exactly what happens with me too, although I typically have it set as DSK4. I just can't trust it with source code... Please PM me about the Horizon RD details.

[+Lee Stewart]

OK, it turned out that using END START instead of END somehow corrupts the GPLLNK utility. It took me a while to figure out why perfectly good code was misbehaving, until I remembered that I had a similar issue while coding the Chaos programs. I still don't have a clear explanation as to why this is the case, and I would love for someone here to enlighten me.

 

I am having a similar issue and cannot find an answer anywhere. Have you been enlightened? I will eventually figure it out; but, I would rather short-circuit that painful process!

 

...lee