Code under OS ROM

[Code under OS ROM]

Can anyone explain what the access to the stack is for in the Turbo Basic XL NMI handler? I've decided to adapt this code but it's giving me trouble.

 

handler:
		bit NMIST
		bpl not_dli
		jmp (VDSLST)
not_dli:
		pha
		txa
		pha
		lda #high exit_int
		pha
		lda #low exit_int
		pha
		tsx
		lda $105,X
		pha
		cld
		pha
		txa
		pha
		tya
		pha
		inc PORTB
		sta NMIRES
		jmp (VVBLKI)

exit_int:
		pla
		tax
		dec PORTB
		pla
		rti

 

I mean the "LDA $0105,X" part...

[SpartaDOS X 4.42]

It would be nice to configure configure SDX to ignore the first 64KB and use instead everything above.

something like:

DEVICE SPARTA BANKED 1

 

furthermore the RAMDISK device driver should be ignoring the first 64KB too.

When configured to "USE BANKED", I believe SpartaDOS X always grabs the uppermost extended banks first. This is also true of the RAMdisk driver. So, if you had 8 extended banks, and you used one bank for SDX and three for a RAMdisk, you'll always have the lower 64K of extended RAM free.

[Code under OS ROM]

If you care, I could dig out my Dos 2.XL which also resided under the Os ROM - it did a couple of additional tricks, the disk buffers were also placed under the Os, thus it only required like ~170 bytes of precious conventional RAM space, all only for the jump-ins and interrupt-handling.

 

Some commented source code for a real application that resides under the OS would be worth studying. This discussion is raising some very interesting points.

 

If you wanted to, you could "fudge" the handling of Interrupts.

 

For an NMI, just handle the DLIs yourself since it's only a couple of instructions.

For VBlank, you could put a return address and processor status onto the stack so that your code gets control back.

 

So, the flow would be:

Is it DLI?

If Yes, JMP via ($200)

Save registers on stack.

Switch OS back in.

Retrieve the pre-VBlank Processor status value from the stack. This is needed so that the Interrupt mask status bit can be read correctly by the OS routine before Stage 2.

Push Processor Status and our return address onto stack.

CLD, push registers onto stack (these will be discarded later).

JMP via ($222)

<normal OS VBlank processing now takes place with ROM switched in>

 

You will then have control back when the normal sequence pulls registers and does an RTI.

Then all you need to do is switch the OS ROM back out, and return from the Interrupt as normal (pull regs, RTI).

 

You could use a similar technique for IRQs.

This is the system I'm going to adopt. For those interested, it will result in a variant of my word processor with a 24K main text buffer, more macro space, etc.

Or he can over-write the international charset w/code as there's 1024 bytes there.

I can use the space occupied by both character sets since the program only accesses them in order to copy the font into its own buffer in main memory (where it can be modified or replaced entirely by a user-defined font).

[Code under OS ROM]

Not necessarily. You can place own vector at the NMIVEC, that points to a RAM routine, which enables the OS-ROM, calls the (f.e.) VBL routine, disables the ROM upon return, and gets back to the program. This involves storing a fake return address onto the stack, but will work, and you can have both the code under the ROM plus system interrupt routines enabled.

 

Excellent, thank you. It's so easy when someone tells you how I'd looked into this ten or more years ago and it seems so obvious now you've explained it. The CIO gets handled in a similar way: all JSRs to CIOV are simply re-routed to a routine which sets bit 0 of PORTB, calls the real CIOV, then disables the OS again and returns to the main program. Great...

[Code under OS ROM]

What's generally the best way of doing this? Obviously it's a common technique on the Atari XL to place programs in the shadow RAM under the OS at $C000-$FFFF, and Turbo Basic, SpartaDOS, and dozens of other programs do it. But surely the main 'loop' of an application must reside in conventional RAM and call routines under the OS ROM after first disabling interrupts, etc. I've been trying to adapt an existing program to run under the OS ROM but it's proving a headache. Clearly anything that calls the CIO or re-enables the interrupts must reside outside the OS region and enable the OS ROM beforehand. I've tried disassembling Turbo Basic for some ideas but it's kind of daunting without any comments...

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

Latest beta test version and an add-in for testing with emulators here. I've found that many emulators don't properly process the keys needed to access extended memory with LW, and this was causing enormous confusion when testing the extended RAM detection routines in the latest beta versions. The BANKUTIL.MAC add-in is loaded just like a normal macro and lets you select extended memory banks with <CTRL>+<T>. It also displays a hex listing of the bank switching masks if you press <SHIFT>+<CTRL>+<T>. Hope this helps if you're using LW with an expanded machine.

 

I hope to get the DOS 2.5/MyDOS/DOS-XE RAM disk code finished soon, plus any amendments to the RAM routines, so if people are still having problems with LW not detecting their RAM properly, I'll need to hear about them soon.

[New Atari8 Website]

must have been when they went to the smaller (A5) format flash

That's right. I started buying what was by then New Atari User in about 1989, but not long after that it went subscription-only. I can't remember when it went to the A5 format... about 1994 I think. I only wish I'd started to contribute a bit earlier. Issues were getting very sporadic towards the end. It's clear they were having difficulties and that subscription rates were dwindling. It's nice to see that someone's laboriously uploaded all the content onto the web, though. The internet makes things so much easier these days. Running a paper-based publication for the Atari8 in the late nineties must have been a real labour of love for Les Ellingham, the editor.

[SpartaDOS X 4.42]

Brilliant, thank you! Can't wait to try this out. The list of new features is just like my personal wish-list for SpartaDOS X... this seems a comprehensive and well thought out upgrade.

[New Atari8 Website]

which programs did you write for the magazines flash and which magaiznes were they intended to be published in

I subscribed to the UK Magazine Page 6, which later became New Atari User. I submitted RIF SpartaDOS Utilities, XEDIT, and The Last Word for inclusion in their PD catalogue very late in the life of the magazine. They published XEDIT (I have a copy of the library disk), and RIF SpartaDOS utilities (along with XEDIT) is in the online Page 6 PD Library. Page 6 was the only place I ever submitted the programs, and I never got any response about The Last Word (the word processor, which was the last and biggest project I undertook).

 

As regards the website, I've set up a favicon and updated the page titles, so interested readers may wish to update their bookmarks.

 

http://www.getsly.com/atari/

[New Atari8 Website]

I'm glad you like the site. Still more work to do, but I've updated it to include the XEDIT text editor (almost forgot about that one!).

[New Atari8 Website]

It's not much - just a place to offer my programs for download. I hope you like it, though. Suggestions welcome, although I'm aware some of the pages aren't finished yet!

 

My Atari8 Website

 

Note photo on masthead. Yes - I will add credits eventually!

[Merry Christmas]

Very best wishes to everyone on the forum for Christmas and the New Year!

 

Jon

[MA65 Macro Assembler for SpartaDOS with XEDIT]

What are the limitations on the demo version of the Fast Assembler, by the way? Just the lack of documentation?

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

well.. I'll help you test it. I have Mega-HZ 512K in my desktop 800xl + AtariMax 32n1 OS and several Rambo 256k 800xl's also.

 

That would be great, thanks. Once we know these memory detection routines work, there's just the RAMdisk code for other DOS systems to add.

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

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

 

Nooooo... (not that...)

Good! It would be a major headache to program, but I have about ten bytes free so the code's got to go somewhere. Using an extended bank for the macro and paste buffer would free up a couple of kilobytes, but the program would be virtually unusable on a stock 64K machine. When I wrote the program ten years ago I hit a brick wall with regard to lack of memory and the wall is still there...

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

LWBeta22.zip

Version for testing with various memory upgrades, on real hardware and under emulation. LW will report a maximum of 10 banks since that's all it can use (that's 9 extended banks, plus the main bank). The main bank is on SHIFT+CTRL+1, and the rest are on SHIFT+CTRL+2 to SHIFT+CTRL+0. This version will avoid SDX banked usage and RAM disks, but will cause problems with RAM disks under other DOS versions. Any sample code for detecting RAM disk size under older versions of SpartaDOS, DOS 2.5, MyDOS and DOS XE would be appreciated, as would any bug reports for this version.

 

Note that this is a test copy, so please make this clear if you offer it for download elsewhere. I'm pleased to see LW hosted here http://atarionline.pl/v01/index.phtml?ct=u...d#The_Last_Word, but if you're hosting it, could you please let me know. This makes it easier for me to notify people when new versions come out. I also aim to host the program on my own website in the near future.

 

Thanks!

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

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...

[MA65 Macro Assembler for SpartaDOS with XEDIT]

http://atariki.krap.pl/index.php/Fast_Assembler

 

hmm, FA is not freeware "Razem z pełną (płatną) wersją asemblera autor dostarczał dokumentację dotyczącą programowania dla SDX."

 

FA demo version from SYZYGY #8 (DISK3) http://madteam.atari8.info/scena/syzygy8.zip

 

Excellent. For those of us thinking of buying the Fast Assembler - can we expect English documentation? In the meantime, I'd still like to understand the SpartaDOS X relocatable file format and incorporate the means to create same in the freeware MA65 assembler.

[MA65 Macro Assembler for SpartaDOS with XEDIT]

I think that symbols (printf smb 'PRINTF') are one of greatest features of spartados x.

They make programming for sdx very fast and easy.

 

If I had a breakdown of the SDX relocatable file structure, it would be fairly easy to add support for symbols to MA65. Then we could have an SDX programming environment right on the Atari hardware.

[Test for Extended RAM]

Have adapted code from the "SmartRAM" RAMdisk driver, and it works properly with all extended memory emulated in Atari800Win. I'll release a beta shortly, which will need testing on real hardware if anyone fancies trying it. Still to add is code to avoid SpartaDOS banked memory/RAMdisks, and similar routines to avoid MyDOS/DOS 2.5/DOS XE expanded RAM usage. At least SpartaDOS X is easy enough to do using COMTAB.

[Test for Extended RAM]

I'm working on a routine to allow my word processor to configure itself automatically for a variety of extended RAM configurations. The routine I've come up with, while it works for a standard 130XE, is having trouble recognizing other set-ups. Does anyone have a routine I can use to build up a table of PORTB bank selection masks which works with a variety of RAM upgrades? I assume SpartaDOS X, for example, includes code which recognizes most memory set-ups.

[RIF SpartaDOS Utilities]

mhm. strange. I could not bring the flash-utility to work properly on my setup ..

 

however, here: http://atariarea.krap.pl/

respectively here: http://atariarea.krap.pl/files/toys.zip

 

is a nice blink-cursor utility which works really nice.

 

grtx,

\twh

 

Really nice site - thanks for the link! The cursor blink utility works really well - all I will say is that the cursor still blinks when moving so is easier to lose.

 

Anyway, I'll have to disassemble mine to see why it doesn't work - I can't find the source code.

[MA65 Macro Assembler for SpartaDOS with XEDIT]

Hi,

 

I have this MADS sample from KMK. How would that translate into MA65 ? Especially the MADS specialities like "smb, blk, reloc" and so on probably don't work in MA65.

 

PRINTF	smb 'PRINTF'

blk reloc main

start	jsr PRINTF
.byte $9b,'Hello world!',$9b,0

jsr PRINTF
.byte $9b,'My numbers:',$9b
.byte '%b, %d, %x',$9b
.byte '%e, %l',$9b,0
.word bdec,wdec,whex,tdec,ldec
rts

bdec	.byte $FF
wdec	.word $FFFF
whex	.word $FFFF
tdec	.long $FFFFFF
ldec	.word $FFFF,$FFFF

 

Or the other way around, do you have a little MA65 source code sample for some command line driven tool which I could use to start with?

 

grtx,

\twh

 

Here's the INCLUDE library I used to use, along with the source to the UNSEG.COM program:

 

UTILSRC.zip

 

I hope it's of some help: I won't have time to provide something more tailored until tomorrow. I've just been studying a piece of code similar to the one you've given, and I was wondering about the structure (I haven't yet read up on the MADS "specialities" yet!). Is this program structured as a relocatable SDX utility?

 

------------------

 

Addendum: The print statement at the start of UNSEG.A65 uses the internal MA65 Date and Time variables I mentioned in the previous post! The variables proper appear at the very end of the source code. I included them so that programs could be auto-stamped with the date and time of assembly.

 

I'd like to interface the SpartaDOS library I wrote with the internal routines in the latest SDX cart. It's something I'll have a go at when I get time...

[MA65 Macro Assembler for SpartaDOS with XEDIT]

Excellent toolset!! Really nice in combination with the batch-abilities of SDX and your great Xedit.

 

--------

 

with MA65 I can now code small SDX tools with parameter support just directly on the Atari within SDX. really cool!!

 

grtx,

\twh

 

Thanks! Really glad you like the tools, and it's GREAT to hear they're being used after all these years gathering dust in a disk box.

 

And a little bug report:

% ma65 test /m O: /l A:

 

does not generate two files but just one (always the listing). Both parameters allow a different path but on a "PRN" file is generated.

 

In hindsight the manual is probably not very clear on this, but it's intentional that only one listing file is produced even if both a symbol map and source listing are specified. I guess (can't remember) that the filename specified after the "/L" command takes precedence. If I remember rightly, the only time the filename for the "/M" option is used is if you just wanted a symbol map WITHOUT a listing. Otherwise the symbol map is always appended to the main listing file.

 

One more question: what's the right way to binary-include a file like a font or a picture? In MADS our often use .incbin ...

 

MA65 does not have a "literal" include command, but I can immediately see what a useful feature it would be. It's something I could easily add to the program, along with a couple of other things:

 

- An internal "Pass" variable

- The ability to output non-segmented object files (removing the need for the UNSEG.COM utility)

 

Also, if you study the MA65 executable, there are some date and time variable names hard-coded into the program at the very end but I can't remember how to use them! Hopefully when I get time I'll figure them out using the source code.

 

It sounds like your programming environment is much the same as mine used to be on the Atari ten years ago. I used to churn out Sparta utilities quite quickly using a library of standard routines in INCLUDE files... needless to say I'll release them when I write up the documentation. I'll also include the source code for some of the Sparta utilities as examples.

 

Writing SpartaDOS utilties was by far my favourite programming activity, and it would be great to gather together commonly used assembly routines for a common programming library for the latest versions of SDX.

[Score! New In Box 1200XL! (pic)]

Thanks everyone, I'm psyched. The 1200XL is my favorite Atari machine. I thought about keeping it as part of my collection, but how could I enjoy it unless I use it? I'm a basic user, so I don't need RAM upgrades or multi-OS mods. I'll try it as-is first, but if the video is poor, I may have it modded for better video. Can this thing do RGB?

 

 

Would it be possible to use this photograph or part thereof on an Atari-related web-page I'm planning to put together? It's already my Mac OS X wallpaper, and very nice it looks too!