The Last Word - A New Word Processor for the XL/XE! (now NTSC-compatible)

[drac030]

What kind of expanded memory setup are you using? I think the idea of the program auto-sensing expanded RAM is excellent, by the way, and I have a couple of ideas how I would go about implementing it. It could be throw-away code in the initialization routines, so the actual program in memory need not grow in size.

 

I have tried this on A800Win with 320K Compy Shop extension enabled. I can try it on a real 130XE as soon as it returns to me from upgrading.

 

As about automatic bank allocation, my advice would be, when under SDX, to use the SDX memory management routines. This would enable the program to "see" the Axlon extension too (provided that it works on an 800 at all). I can supply some example code, if you want.

 

Thanks for the explanations on how to get the required characters. I will experiment with this and will tell you, if this is convenient enough and there are no additional problems.

 

Addendum: I've been reading through the manual and I'd forgotten that RAM Bank configuration is only implemented from the config file loaded when the program first starts (usually LW.CFG).

 

This is not a problem, because I have first created an UNNAMED.CFG with the config program, and then copied this new CFG file onto LW.CFG, and then executed the LW. This didn't help, the program reported 15k buffer as before.

[flashjazzcat]

As about automatic bank allocation, my advice would be, when under SDX, to use the SDX memory management routines. This would enable the program to "see" the Axlon extension too (provided that it works on an 800 at all). I can supply some example code, if you want.

 

That would be great, thank you - I'd be very interested in some code examples. As a matter of fact I've always wanted to understand more about many aspects of the SpartaDOS X code base.

 

Having reviewed the documentation for The Last Word, I believe I have left all necessary portb bits available to handle any memory upgrade, but the proof will be in the testing, of course, and my own testing is incomplete since I have just been running the Atari in emulation for a little over a week. I think the auto-RAM sensing will be an interesting project, although I must be careful to preserve compatibility will different DOS versions (unless I was to make a special SpartaDOS only version).

 

As for the international characters, the manual makes a big deal of the program's ability to display and print international characters, and I recall that this was one of the main features I wanted to implement in my program (I was writing about a lot of French Novels at the time), so I'm sure you'll be able to make the software do what you want.

Edited December 3, 2008 by flashjazzcat

[Mathy]

Hello Flashjazzcat

 

Why not:

 

1) Test which DOS used

2) If Sparta load Sparta-RAM-routines into memory overwriting the DOS test routine

3) If not Sparta load different-DOS-RAM-routine into memory overwriting the DOS test routine

 

greetings

 

Mathy (who's better in comming up with idea's then realising them)

[flashjazzcat]

Hello Flashjazzcat

 

Why not:

 

1) Test which DOS used

2) If Sparta load Sparta-RAM-routines into memory overwriting the DOS test routine

3) If not Sparta load different-DOS-RAM-routine into memory overwriting the DOS test routine

 

greetings

 

Mathy (who's better in comming up with idea's then realising them)

 

That's pretty much what I'm thinking, although all the code will be jettisonned once the initialization routines are run. Their only purpose is to set up the portb mask table, then they can be discarded. That's good, because it means the set-up routines can be quite elaborate. I think the difficult part will be finding out how to test for RAMdisks in the likes of DOS XE.

 

As for SpartaDOS X, BANKFLG and NBANKS (coupled with a routine to establish the number of banks on the machine) should provide all the information needed (since SDX uses banks from the top down, LW can use all available banks from the bottom up). I'll need information about earlier SpartaDOS versions and how to establish RAMdisk size. My plan to test for total memory size is roughly as follows:

 

Repeat

 

Write value to $4000

Write next possible bit-mask in series to portb ($D301)

Test if value at $4000 has changed

If yes, save bitmask and increment # of banks by 1

 

Until all possible bitmasks used

 

I can see problems if some of the bits in portb are unused by the memory expansion, however: one might end up with the same bank listed more than once. The SpartaDOS X RAM Disk driver probably contains just the kind of routine I need.

 

Edit: Found some code here: SmartRAM RAMdisk Source

Edited December 4, 2008 by flashjazzcat

[flashjazzcat]

Just a note for Atari800MacX users: The emulator doesn't appear to pick up <SHIFT>+<CTRL>+<Cursor> combinations properly with The Last Word (at least mine doesn't). The Win version is fine, though.

 

EDIT: My mistake: The Mac version of the emulator maps these Atari keystrokes to different keys to the Win version...

Edited December 4, 2008 by flashjazzcat

[flashjazzcat]

Source code and manual have just arrived by email. Can't wait to get started on this expanded memory recognition routine, but first I'll prep and upload the source and manual for download. I'll release the manual as an ATR disk image (it's in Last Word file format so offers a useful example of how to format text), but I'd also like to release a copy in PDF format (a la the SpartaDOS X Manual). The source code is in MA65 format (my own assembler) but I'll run it through some kind of filter to make a MAC/65 listing as well. I've also got XEDIT (a text editor for SpartaDOS which can handle 22K files), plus the source code for that, together with source code for MA65 and various SpartaDOS utilities. I hope to get everything released in the next few days.

Edited December 5, 2008 by flashjazzcat

[flashjazzcat]

Manual now released:

 

http://www.atariage.com/forums/index.php?showtopic=135703

 

Souce code to follow...

[drac030]

The LW does not work on the 65C816.

[flashjazzcat]

The LW does not work on the 65C816.

 

I don't know a lot about this chip. How can we go about finding out why LW doesn't work with it?

[drac030]

The LW does not work on the 65C816.

 

I don't know a lot about this chip. How can we go about finding out why LW doesn't work with it?

 

It should work as long as no illegal 6502 opcodes are used. Also, it should work with the 65C816 dedicated OS as long as no illegal OS calls are used (illegal = everything outside the $E400-$E48C and $D800-$DFFF).

[flashjazzcat]

The LW does not work on the 65C816.

 

I don't know a lot about this chip. How can we go about finding out why LW doesn't work with it?

 

It should work as long as no illegal 6502 opcodes are used. Also, it should work with the 65C816 dedicated OS as long as no illegal OS calls are used (illegal = everything outside the $E400-$E48C and $D800-$DFFF).

 

Interesting: LW uses NO OS calls whatsoever, apart from calls to DOS via CIOV. It uses no FP, screen or keyboard handler calls, but DOES reference the OS keyboard lookup table if I recall correctly.

 

How far does the program get when running on a 65C816 system? I'd be interested in debugging it.

Edited December 9, 2008 by flashjazzcat

[drac030]

Interesting: LW uses NO OS calls whatsoever, apart from calls to DOS via CIOV. It uses no FP, screen or keyboard handler calls, but DOES reference the OS keyboard lookup table if I recall correctly.

 

How far does the program get when running on a 65C816 system? I'd be interested in debugging it.

 

The keyboard definition table is separate problem. The LW should definitely reference it through the keydefp, not directly.

 

As far as I tried, the LW does not so far, it simply hangs as soon as it is loaded. Nothing changes on the screen. The PC is in some weird place in ROM. trub says that the LW works when one disables the memory extension. This may be anything, e.g. a conflict with SpartaDOS X (which resides in one of the banks).

[flashjazzcat]

Interesting: LW uses NO OS calls whatsoever, apart from calls to DOS via CIOV. It uses no FP, screen or keyboard handler calls, but DOES reference the OS keyboard lookup table if I recall correctly.

 

How far does the program get when running on a 65C816 system? I'd be interested in debugging it.

 

The keyboard definition table is separate problem. The LW should definitely reference it through the keydefp, not directly.

 

As far as I tried, the LW does not so far, it simply hangs as soon as it is loaded. Nothing changes on the screen. The PC is in some weird place in ROM. trub says that the LW works when one disables the memory extension. This may be anything, e.g. a conflict with SpartaDOS X (which resides in one of the banks).

 

Interesting about LW working when the memory extension is disabled: that certainly offers a clue. Have just been reading through the docs for the 65C816 XL/XE OS Revision 65C816 OS but I haven't seen any obvious conflicts yet.

 

I've just checked the source code and LW does indeed reference the keyboard table directly at $FB51, so if it isn't still there, it isn't going to work. I'll use the KEYDEF pointer in subsequent revisions.

[trub]

Interesting about LW working when the memory extension is disabled: that certainly offers a clue..

To be more precise: the only config that lets me see the main editor screen on my 65816 system is with extended memory switched off and SDX enabled. This does not mean that the editor works ok is this setup. If I load the program from DOS 2.5, it just crash during loading (no logo shown). My friend who also has an 65816 equipped system wasn't able to run the program too.

I tried the same with a stock 130XE and everything looked fine. This make me suspect that the 65816 is a concern here. Do you use any of the "undocumented" opcodes ? In 65816 they all do a NOP.

[flashjazzcat]

To be more precise: the only config that lets me see the main editor screen on my 65816 system is with extended memory switched off and SDX enabled. This does not mean that the editor works ok is this setup. If I load the program from DOS 2.5, it just crash during loading (no logo shown). My friend who also has an 65816 equipped system wasn't able to run the program too.

I tried the same with a stock 130XE and everything looked fine. This make me suspect that the 65816 is a concern here. Do you use any of the "undocumented" opcodes ? In 65816 they all do a NOP.

 

I deliberately avoided using 65C02 opcodes or any "illegal" instructions. I'm inclined to think there's a memory conflict with the 65816 OS. LW wipes out the entire upper half of page zero, CASBUF in page 3, and all of pages 4, 5, and 6. Would that cause problems with any 65816 locations?

Edited December 10, 2008 by flashjazzcat

[trub]

I'm inclined to think there's a memory conflict with the 65816 OS. LW wipes out the entire upper half of page zero, CASBUF in page 3, and all of pages 4, 5, and 6. Would that cause problems with any 65816 locations?

No, the problem persists with the original Atari OS or QMEG OS ('816 doesn't require a customized OS, although such is needed to get its full potential).

If it may help, the program hangs after loading sector $68 from the XFD you supplied.

[trub]

I deliberately avoided using 65C02 opcodes or any "illegal" instructions.

Ok, I think I found the cause

Look at the code which is loaded at address $3000-$303A and which seems to change the display list. You put there a byte which does not correspond to any 6502 instruction. It is $82 just after LDA VCOUNT. I changed it to a NOP (as well as the following $9B) and the program now loads without problems.

[flashjazzcat]

I deliberately avoided using 65C02 opcodes or any "illegal" instructions.

Ok, I think I found the cause

Look at the code which is loaded at address $3000-$303A and which seems to change the display list. You put there a byte which does not correspond to any 6502 instruction. It is $82 just after LDA VCOUNT. I changed it to a NOP (as well as the following $9B) and the program now loads without problems.

 

Well done and thanks! This is a bug that must have been introduced when I implemented the NTSC fix. I thought I'd changed the $9B to $82 with a sector editor but obviously I hit the wrong byte.

 

I'll recompile the altered code now and upload a fixed version. Brilliant work!

[flashjazzcat]

Have recompiled and tested under NTSC emulation. Here's the fixed disk image:

 

LW_NTFIX.zip

[trub]

The fixed version loads without problems, thank you!

 

It may be interesting, what was actually going on:

- 6502: $82 is an "illegal code", which is a kind of NOP skipping next byte ($9B here); so nothing really bad happens, the program continues normally

- 65C816: $82 is an opcode for BRL instruction (unconditional Branch Long), which takes 2-byte argument (branch offset); the following two bytes form an offset of $D09B (negative number), so the execution continues at some place in memory with undetermined contents, making a system crash.

[flashjazzcat]

The fixed version loads without problems, thank you!

 

It may be interesting, what was actually going on:

- 6502: $82 is an "illegal code", which is a kind of NOP skipping next byte ($9B here); so nothing really bad happens, the program continues normally

- 65C816: $82 is an opcode for BRL instruction (unconditional Branch Long), which takes 2-byte argument (branch offset); the following two bytes form an offset of $D09B (negative number), so the execution continues at some place in memory with undetermined contents, making a system crash.

 

Yes - that's exactly correct. The code segment in question is the routine that was originally causing the program to hang on NTSC machines:

 

VBWAIT

LDA VCOUNT

CMP #$9B

BNE VBWAIT

RTS

 

Its purpose was simply to wait until a complete screen frame had been drawn. However, on an NTSC Atari, VCOUNT never reaches $9B, so the program went into an endless loop. My fix was to simply replace $9B with $82. There are two instances of this code in the program; however, in one instance I clearly overwrote the CMP op-code with $82 by accident. This had the deceptive effect of fixing the NTSC bug, because the missing CMP op-code meant that any non zero value in VCOUNT would end the loop on a 6502 machine. Not so with the 65C816...

 

Well done!

Edited December 10, 2008 by flashjazzcat

[drac030]

VBWAIT

LDA VCOUNT

CMP #$9B

BNE VBWAIT

RTS

 

Its purpose was simply to wait until a complete screen frame had been drawn.

 

This can be done much safer with RTCLOCK:

 

	lda rtclock+2
wait:
cmp rtclock+2
beq wait

 

And it is yet safer to load ANTIC/GTIA registers through shadows. The loop is not necessary then.

[flashjazzcat]

This can be done much safer with RTCLOCK:

 

	lda rtclock+2
wait:
cmp rtclock+2
beq wait

 

And it is yet safer to load ANTIC/GTIA registers through shadows. The loop is not necessary then.

 

Yes, I can see how that would work well. The VCOUNT routine works, anyway, although your code is a byte shorter! I used the wait routine to synchronise enabling and disabling of the display list interrupt (NMIEN) with the vertical blank. It was a small issue but seemed to get rid of very occasional screen glitches.

 

I have a attempted to convert the LW source code (all 8,000 lines of it) to a format compatible with the MADS or ATASM assemblers, but have encountered numerous problems making the MA65 listing compatible with either. MA65 has an idiosyncratic source code format (although it's not alone), and while I had some success making it work on a cross-assembler, getting rid of all the 'illegal' string characters that MA65 allows is proving a pain. I might write a program to convert the source code to MAC/65 native format, and release it like that. In any case, however, I'll be releasing my assembler along with the source code. My immediate plans are to implement the auto-RAM sensing routines, and in the future I'd like to release a special SpartaDOS X only version, which takes advantage of RAM under the OS to allow for a larger macro buffer and main text buffer, permanent reinstatement of the icon menu, two extra lines of text on the screen, an even better disk utility menu, and a programmer's mode, which displays line counts and expanded tabs on the screen.

Edited December 13, 2008 by flashjazzcat

[drac030]

your code is a byte shorter!

 

It is also TV-system independent

[flashjazzcat]

your code is a byte shorter!

 

It is also TV-system independent

 

...and is now part of the program.

 

OK - I'm almost ready to release a Beta of LW which includes automatic detection of a variety of memory upgrades. Still to add is code to detect extended RAM usage by RAMDisks in DOS 2.5/DOS-XE/MyDOS. In the meantime I just want to make sure the memory bank detection works OK.

 

This might be a good time to ask what could be added to the "wish list" of features for LW. Since I'm rapidly running out of code space, what I'm considering is:

 

- Using an extended bank of RAM for the macro/paste buffer if more than two banks are available. This would allow for larger macro files, and direct, in-situ editing of the macro buffer - useful for debugging macros.

- Use of memory under the OS for sections of program code. Obviously this knocks out compatibility with disk-based SpartaDOS and DOS XE.

- A vector-table fixed at $8000 for writing machine code add-ins. This would cure the current problem of add-ins requiring re-assembly whenever routines in the main program move.

 

These are just a few ideas...

Edited December 21, 2008 by flashjazzcat