Jump to content

Recommended Posts

Oh dear :-( That doesn't sound good at all. I use it in bank 0, system.a99 (have a look at the start of the file) but it's always worked fine for me. I'm not using the latest version on the assembler though.

 

It's unfortunate that Cory Burr chooses not to engage with the TI community - it means bug fixes that could be trivial for him to fix have to be suffered for a long time.

 

Still, I shouldn't moan too much - ASM994A is a gem of a program.

That is unfortunate.. maybe he made it ignore DORG? I've only used AORG and RORG, since those are the only two that worked with the original E/A system (IIRC).

 

It is a nice assembler, but yes, I would love a week with the code to fix up a few things. ;) Perhaps some day he will release it to us.

Can I ask a silly question, slightly off topic?

 

Again... this may seem silly--

 

What is wrong with the original assembler running in Overdrive mode of Classic99? It's pretty damned fast... Is there something Cory's assembler does that can't be done with the original assembler? Is it that much more convenient to use?

 

Sorry if this sounds trivial, but an assembler's an assembler, right? And if the E/A assembler works for ALL TMS9900 assembler purposes, would it not be the ideal assembler to use?

It's a little more convenient to stay in one environment (Windows in this case), and even with accelerated emulation, it's faster than Editor/Assembler. It also integrates linking stages and can produce a cartridge file out of the box.

 

It's still not my 100% preferred ideal, but it works too well for me to want to write a new one. :)

I would think that you're jumping environments anyway though, right? I mean, you'll have to go back to the TI to run the program... Whether you jump there before or after assembly would seem like the same jump, right? =)

 

 

That cartridge file, though... that would be a significant advantage...

 

So... you gonna write a new one? =)

I now have the ALC whipped into shape enough to start testing it. At first, I had a little trouble with my new file-sector access routines that I have fixed to the point of proper reading of a blocks file. The 40-column editor works fine as far as my tests have gone. The 64-column editor is going to take a bit more work—I must have messed up some manual block transfers. By the way, I used @Willsy's TurboForth to make my fbForth system BLOCKS file from a text file I had modified to the format I wanted. It worked like a charm! It's going to take a little time to test all the words I've added and those I've modified.

 

What is interesting is the way I'm managing to load and run fbForth. As you probably know, the TI Forth system disk has two program files: the boot program, FORTH, and the binary file, FORTHSAVE, that FORTH loads after it does some setup. These two files are created from nine source files that are first used to create three object files. The boot program, FORTH, is created from a single source file, which only needs to be re-assembled when the number of bytes in the binary, memory-image file, FORTHSAVE, changes. The "interesting" thing mentioned earlier is that I don't need the boot program to load and run (E/A option 3) the system for almost everything. I can load the two object files that will (may?) ultimately become part of the memory-image file and then start the system by typing "ENTLNK" at the E/A "PROGRAM NAME?" prompt. I said "almost everything" because the object file that loads in low memory seems to have been a work in progress in that I can actually launch fbForth (and TI Forth before it), but at least one function (CIF) is orphaned.

 

I don't think it would be difficult to fix those insufficiencies such that I wouldn't need the boot program at all. I'm pretty sure the reason TI did what they did was to conserve space, not for speed, because the system blocks consume 69 KB, which leaves only about 20 KB for programs. The two object files from which FORTHSAVE is composed total 37 KB and for fbForth, they total a touch over 40 KB—obviously too big. However, the 40+ KB for fbForth reduces to about 19 KB as compressed object files, which seem to actually load faster than the uncompressed variety. fbForth's system-blocks file currently uses 70 KB, leaving nothing to spare if I',m going to get it all onto a single 90-KB disk. I actually have 6 KB to play with because I have 6 KB of empty system blocks.

 

So ... My options are to produce

  1. A single compressed object file that includes the entire system and hope I can keep it to 19 – 25 KB—probably doable;
     
  2. À la TI Forth, a single memory image file (10 – 11 KB) and a boot program modified to reduce the file buffer allocation from the default of 3 to 1 or 2 because the larger memory image will step on the current allocation; or
     
  3. Two memory images, one for low-RAM and one for high-RAM, to be loaded by an only slightly modified boot program, thus keeping the loads from clobbering the default file-buffering.

I'm inclined to try #1. I'm torn because that actually might be the most work, but it might be fun. There are two major chores. The first is rolling the boot program's functions, a few of which are hobbled or missing from the rest of the system, into the new program. The second is to avoid collisions of labels—possibly difficult enough to be a deal-breaker. On the other hand, several EQUates would be obviated. H-m-m-m ...

 

...lee

I would think that you're jumping environments anyway though, right? I mean, you'll have to go back to the TI to run the program... Whether you jump there before or after assembly would seem like the same jump, right? =)

 

It's not, though. ;) A lot less typing needed with a PC-based assembler. With Asm994a I just click "build" and I have object files ready for Classic99 to boot. Same when I'm working with GCC, I just type 'make' and it's ready to go. With the TI Editor/Assembler, I have to type all the filenames (and load extra programs with extra typing if I want a PROGRAM image file). It's just a faster workflow.

 

So... you gonna write a new one? =)

 

Nope. :)

OK ... Here's a short video showing fbForth starting up. I'm using the clunky, interim loading method I mentioned in an earlier post.

 

fbForth_v0.9.wmv

 

...lee

  • Like 2

OK ... Here's a short video showing fbForth starting up. I'm using the clunky, interim loading method I mentioned in an earlier post.

 

fbForth_v0.9.wmv

 

...lee

 

Yeeeeow! Now you're kickin' ass! Way to go!! :thumbsup: :thumbsup: :thumbsup:

It's not, though. ;) A lot less typing needed with a PC-based assembler. With Asm994a I just click "build" and I have object files ready for Classic99 to boot. Same when I'm working with GCC, I just type 'make' and it's ready to go. With the TI Editor/Assembler, I have to type all the filenames (and load extra programs with extra typing if I want a PROGRAM image file). It's just a faster workflow.

 

Indeed. TurboForth consists of around 40 source files, and is rather large. The listing file that is produces is just under 14,000 lines. Cory's assembler eats it all up in around 2 seconds on my laptop.

 

I don't even want to think about assembling that with TI's assembler! Even with Turbomode switched on in Classic99!

 

In actual fact, I'm sure the TI assembler couldn't assemble it. Not without some extensive changes. I think there are simply too many labels in the source code: An old version of the source that I have kicking around on my work PC shows me I have 1458 labels in the source code. If we assume 10 bytes per label, that's 14.5K just to hold the symbol table in memory.

 

I dunno, maybe it could assemble it - IIRC the assembler itself is only 8K and sits in low memory.

 

It would take a long time though!

 

Also, I like notepad++ and the TMS9900 syntax highlighting. (See screenshot below).

 

Mark post-24932-0-38765200-1370854690_thumb.png

  • Like 1

Well, I think I have reached the end of the road doing it the clunky way. Once the fbForth address interpreter gets control, the first call to GPLLNK crashes the system! :mad: I know the DRIVER program invokes GPLLNK with slightly different returns than the BOOT program; but, I don't think it's worth the time and headache to troubleshoot it, instructive though it may be. I think I'm going to attempt a single program and just slog through resolving all the label collisions I'm bound to get. I should know something soon.

 

...lee

Wow! This should not have taken this long! I was staring right at the problem and was not seeing it. :woozy: In my definition of GPLLNK in the ALC, I had forgotten a LIT to get the constant on the stack. I was simply translating the following from high-level TI Forth:

 

HEX

: GPLLNK 0 837C C! 10 SYSTEM ;

 

which becomes the following in the ALC for the code and parameter fields:

 

GLNK DATA DOCOL,ZERO,
LIT,
>837C,CSTORE,LIT,10,SYST$,SEMIS

 

I had forgotten the reddened LIT that puts the following constant on the stack, leaving the system twisting in the wind somewhere in GPL-land! The real kicker is I didn't even need "ZERO,LIT,>837C,CSTORE"—the low-level code that the routine calls already zeroes the GPL status byte, which is what that snippet does. :roll:

 

It won't be long, now! I just need to do a little more testing and clean up some of the blocks inherited from TI Forth. I will very soon post a working system to be tested by y'all. :grin:

 

...lee

  • Like 3

I'm still torn on the best way to assemble the fbForth system. Doing it with a single 18.5KB compressed object file seems simplest, but it does take several seconds longer to load than doing it with 2 files—a small boot program that sets up and loads a memory image file of 10-11KB, the way TI Forth was done. I may do it both ways for comparison. It's just that the latter method is a lot more complicated because there are a fair number of hardwired addresses that have to be updated when anything changes—not good programming practice. The former requires only one assembly with any change. Thoughts?

 

...lee

I'm still torn on the best way to assemble the fbForth system. Doing it with a single 18.5KB compressed object file seems simplest, but it does take several seconds longer to load than doing it with 2 files—a small boot program that sets up and loads a memory image file of 10-11KB, the way TI Forth was done. I may do it both ways for comparison. It's just that the latter method is a lot more complicated because there are a fair number of hardwired addresses that have to be updated when anything changes—not good programming practice. The former requires only one assembly with any change. Thoughts?

 

...lee

Although I'm totally green, especially compared to the highly knowledgeable people we have in the community here, I would say do the single object file: only one thing to update if anything changes. Who cares about a few seconds longer load time when fixes and changes are so much easier to employ? ;)

I just tripped over the file-based-blocks improvement and principal raison d'être of fbForth. Not only do you presently need the message blocks (#4 – #5) in every blocks file, but the block (currently, #20) for true lowercase (binary format) for text mode needs to be there, as well. I could move it to block #3; but, I'm beginning to think I need to byte |:) the bullet and use a separate blocks file for this sort of thing. H-m-m-m...This might push me faster toward cartridge space. One possible solution, short of a separate blocks file for messages, would be to automatically EMPTY-BUFFERS and switch to the system blocks file, FBLOCKS, whenever the need arises. The only time I can imagine this would be a problem would be if a user decided to use blocks files to store/retrieve data. I should probably bag the idea. I think I will either warn the user to copy the necessary blocks to any newly created blocks file when MKBFL is used or do it automagically—more code bloat. :ponder: Oh, well...

 

...lee

In the case of the character set being loaded from the blocks disk (sigh... why didn't I think of that??!) you might want to consider putting a header at the beginning of the data on that block. That way, fbForth could determine if the data it is looking at is valid character set data, and load it if it is, but more importantly, not load it if it isn't (leaving the default TI character set in place, presumably).

 

Of course, in a cartridge, you could place the character set and error messages in ROM. Early in TFs development, I was considering reserving 4K of the EPROM space as 'read only blocks'. They would be accessed with negative block numbers, -1, -2, -3, -4 and would house various utilites, or system messages etc. It just needs a trap in BLOCK to check the block number and take a different course of action in the event of a negative block number. I ran out of ROM space though! I nievely thought that 12K would be enough code space! Ha! I need more like 32K of ROM, possibly 64K for what I'd *really* like to do!

 

So, that might be worth considering when you move to an EPROM - that way, you wouldn't have to hack the code so much, just change the code that does the LOADs for the error messages and the character set, and add code to BLOCK to check the block number, and if negative, and within legal limits, don't do a DSRLNK out to disk, just page in the appropriate bank of ROM and copy the contents directly into a block BUFFER, and set the internal buffer allocation tables appropriately so that the system knows it's there. Ta da.

 

Of course, FLUSH would need a tweak too... Just skip over buffers that are assigned to negative block numbers and set them to un-used. :)

In the case of the character set being loaded from the blocks disk (sigh... why didn't I think of that??!) you might want to consider putting a header at the beginning of the data on that block. That way, fbForth could determine if the data it is looking at is valid character set data, and load it if it is, but more importantly, not load it if it isn't (leaving the default TI character set in place, presumably).

 

Good idea! I think, however, I may create a 2-block file with both the text mode true lowercase and the 64-column editor's tiny character set and call it FBCHARS. I should only need to fall back on the TI small caps lowercase when the file is not found.

 

... I naively thought that 12K would be enough code space! ... :)

 

12K!—is that a typo? I though it was a 16K limit.

 

...lee

Hey Willsy....

 

A bit OT, but will the new cart board designed by Jon, Tursi and Jim not solve your "space" issues for the TF ROM?

 

Hell yeah! But I want folk that own V1.0 and/or V1.1 to be able to upgrade their cart to V1.2 by either ordering a new EPROM, or burning their own EPROM at home for free.

 

If I ever do a V2.0 it'll be based on the new FY board design, for sure!

Well, just my opinion, but screw that... When upgrading your car from an older model, you don't just buy a new engine or a new dash board... You buy the flipping whole car. :)

 

I'll take your new TF any way I can get it... I'd buy a new board for it... But just keep in mind, when Windows went from XP to 7, they didn't just send out a "patch" in an email. :)

 

But you are a good man... Prefer current users make the switch and want to make that as inexpensive as possible... That is commendable, good sir... But it must make you feel very "hamstringed" and constricted. :)

 

I'm glad for the new TF and the new cart boards... Wish they could coexist. :)

OK...For now, I'm settling on a single, compressed object file for fbForth, FBFORTH; a 62-block blocks file, FBLOCKS; a 1-block file, FBCHARS, for the true lowercase character set for text mode as well as for the tiny character set for the 64-column editor—that is, if I can figure out how to keep from trashing the currently interpreting block when reading FBCHARS; and a 5-block file, FBMSGS, for messages. This should all fit (barely!) onto a 90KB SSSD diskette or DSK image. That way anyone should be able to use fbForth. It should be a trivial matter to expand FBMSGS and FBLOCKS for larger disks.

 

...lee

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...