Action! Source Code Action! Source Code

[drac030]

That might be due to the "blinking cursor" implementation. If you can provide a disk to reproduce the issue, I should be able to find & fix it.

I am not sure how can I prepare a disk to reproduce this issue, as the QUICKED is located on the SDX cartridge. One should insert the cartridge, start the DOS, type "QUICKED.SYS" (+ Return) at the DOS prompt. Then, when Action is started, the issue will reportedly raise its head. I am unsure what the problem looks like either, because I do not even own an Action! cartridge.

[+slx]

I stand speechless admiring your work Jac! Thanks!

[luckybuck]

ACTION! and the XEP80:

 

Well, as of 2015 they both do not work together. But that shouldn't be the final status.

 

For now, we have for example two pages for that:

 

 

 

Mathy's collection of special stuff

 

AtariWiki V3: The XEP80

 

inside are example for quite well(!) and(!) fast(!) working XEP80.

 

Maybe that will help you all.

[+JAC!]

My idea is to have ACTION! optionally use the standard E: handler also for the 3 things it currently doesn't. This way we should at least get it working, though it probably won't be fast in first place.

[MrMartian]

I am not sure how can I prepare a disk to reproduce this issue, as the QUICKED is located on the SDX cartridge. One should insert the cartridge, start the DOS, type "QUICKED.SYS" (+ Return) at the DOS prompt. Then, when Action is started, the issue will reportedly raise its head. I am unsure what the problem looks like either, because I do not even own an Action! cartridge.

 

That's it so far.. Basically, when QUICKED is loaded, go to Action! and try to load a file into the editor.. It won't show the filename as you type, but assuming you type it correctly the file will show up in the editor. That works fine, but then go to monitor and C for compile, the C won't show up. But, it will actually compile if you hit ENTER... So, it's accepting the keys but not showing them..

[funkheld]

hello, good day.

what asm compiler can compile source please ACTION?

thank you.

greeting

[luckybuck]

In the golden age the microtec cross assembler was used, as far as I know:

 

 

Today:

 

http://mads.atari8.info/

 

is a good option.

 

Anyway, if you can manage the source code to be used with the MAC/65, we can put that on the Wiki and you will never be forgotten...

[funkheld]

hello, thanks.

[+DrVenkman]

So with the use of JAC!'s amazing work turning Action into a single monolithic 16K .xex file, I'd like to finally learn Action! 32 years after the fact. Being new to both Action! and the use of languages loaded from .xex files, is there something obvious that I'm missing with regard to disk access? In others words, if I load the .xex file into my real A8 hardware from my laptop using an SIO2USB device, how can I then save my work? If I use a physical cart and the cartridge file JAC! has provided, I can boot the machine from a real drive with a DOS disk, or a virtual DOS disk image through the SIO2USB device. But since I don't have a flash cart on which to load the Action! file JAC has provided, can someone explain how I can use the .xex file on real hardware and keep the ability to save and load files to disk?

Thanks in advance!

[+JAC!]

.xex is just a "modern" renaming of the ".com"/".exe" file extensions you may know from Atari DOS. Just copy the ACTION! executable to a DOS disk contain "DOS.SYS" and "DUP.SYS" as "AUTORUN.SYS" and you should be able to boot into it. Because DOS is booted first (before it continues loading "AUTORUN.SYS"), it is resident in the RAM at that time. This mean you can use the regular "RD:EXAMPLE.ACT" to "R"read from "D:EXAMPLE.ACT" and "WD:OTHER.ACT" to write it. Haven't tried myself, but should work.,

Edited April 6, 2015 by JAC!

[luckybuck]

Post #67 for real hardware

post #84 for all questions

[luckybuck]

ACTION Disk Version 1.atr

ACTION Disk Version 2.atr

OSS DOS XL 2.30p Color with ACTION 3.6 carts.atr

 

These should work for you.

OSS Action! Version 3.6 with DOS XL 2.20 and REAL files.atr

[+DrVenkman]

Thank you both for your help, JAC! and luckybuck! I'll be digging into these disks and Action! in the coming weeks.

[+JAC!]

Just pushed the recent source changes:

• Compile switch feature_build_version added
• Additional comments for IO and string handling
• Replace numeric constants with symbolic constants (esp. screen_definition)
• Add inner structure to LIB.OPT
• Convert statement definitions from .byte to m_statement
• Convert strings from .byte to m_string

[TXG/MNX]

to witch location are the source changes pushed ?

[+JAC!]

https://sourceforge.net/p/atari-action/code/ci/master/tree/

[+JAC!]

A while I received a question regarding adding support for the upcoming/available accelerator cards and 65816. I though about it, and here's my summary:

 

I see two aspects to it. One is the speed aspect. And there it's in the nature of the 6502 design that you get the best speed not by changing the code, but by increasing the CPU clock. Some FPGA implementations of the 6502 architecture drive this to the maximum by implementing all operations in a single cycle. The 16 bit addressing mode of the 65816 is not really helpful when it comes to speed, esp. because to typically have to switch between 8/16 bit mode and still you only have 3 CPU registers. And also the 6502 already has "256 8-bit registers" / "128 16-bit" registers), namely the zero page. So again, the 16 bit as such don't make that much of a speed difference.

 

The long addressing modes become relevant once you run out of memory to accomplish what you're trying to do. That's nothing I consider relevant for coding ON the Atari 8-bit. That's totally different when it you think about cross compiling. For Pab's ACUSOL, 65816 might be something worth think about

http://atariage.com/forums/topic/223277-developing-a-new-language-acusol/

 

I really see these two projects are complementary. ACTION! for native Atari coding, ACUSOL for cross-dev.

Edited April 26, 2015 by JAC!

[ricortes]

Mostly. Code density on a 65C816 is much better. Some operations like memory move only take ~20 bytes vs. 40 for a 6502.

 

I've never really run out of space on a 64k machine, just cramped occasionally. I agree with your sentiments and anything you'd gain, you'd lose somewhere else. If you go 65C816 then everyone who hasn't upgraded is left out.

 

Anyone that wants to can just use a 65C816 runtime coded for it. IMHO that is the way to do it. The Action system does not care what is in the code blocks. If someone wanted to write a Z80 runtime they could within the limits of the parameter passing.

[Timbit]

I have some questions about the disk images posted by luckybuck.

Why are there four different disks with different Action! binaries? (eg. ACTION.COM, ACTION1.COM, ACTION2.COM)

Are any of these builds based on the fixes to the recently acquired source code?

The included TXT files are not very descriptive. Which is the best or newest one that I should use?

 

Thanks.

[luckybuck]

Hi Timbit,

 

the disk images are just for someone, who doesn't have the cartridge and wanted to have just one version, which works via disk.

 

Anyway, the best option is always the cartridge:

 

ACTION_Version_3.6_(C)_1983_ACS_034M.zip

ACTION_Version_3.6_(C)_1983_ACS_M091.zip

 

Please replace .zip with .car

 

All question about ACTION! can be found here:

 

AtariWiki V3: ACTION

 

except the new findings from JAC!

'

Are any of these builds based on the fixes to the recently acquired source code?

'

No, they are from the 80's to give the users the chance to use ACTION! with the cartridge.

The above carts are the same concerning the code. The user should use version 3.6 or even better the versions published by JAC.

Hope, I could help you.

 

[Kyle22]

I would welcome a 65816 optimized version! This would not be a detriment to the 6502 users, they can have their own version.

 

We must look to the future

[+DrVenkman]

For what it's worth, I tried adding JAC's Action.xex file to a DOS boot disk and renaming it AUTORUN.SYS, then running it in my emulator (Atari800MacX). On the first try it booted to the Action! prompt before crashing. Subsequent attempts with various emulator settings gave similar results - some of the crashes occurred before the Action! prompt, some after, but in no case could I get it to run. However, loading the .XEX file directly worked fine.

 

So yes, we can use something like AspeQt, ProSystem or SIO2OSX to boot the executable but that leaves no way to save files to disk. It would be really great for those who'd like to use JAC's bug-fixed and improved version of Action! had a functional way to do so on real hardware without the need for a modern flash or repro cart.

 

EDIT: Okay for anyone else who may be interested (Tim?), I tried the same thing in Altirra 2.60 (running in CrossOver on my Mac) and get the some problem with the .XEX-to-AUTORUN.SYS trick. I also played around some more with Atari800MacX. Essentially what happens is the file boots. The editor screen comes up and the cursor blinks. But as soon as any keyboard input occurs, it crashes. Running the .XEX directly without booting it from a DOS disk works as you'd expect, but of course you can't load or save files to disk so it's of very limited utility. Again, this is with any emulator I used, and any combination of emulated hardware, memory and OS configuration I tried, with and without the various emulator OS patches. Something about auto-trunning that file just doesn't want to work.

Edited May 17, 2015 by DrVenkman

[fujidude]

EDIT: Okay for anyone else who may be interested (Tim?), I tried the same thing in Altirra 2.60 (running in CrossOver on my Mac) and get the some problem with the .XEX-to-AUTORUN.SYS trick. I also played around some more with Atari800MacX. Essentially what happens is the file boots. The editor screen comes up and the cursor blinks. But as soon as any keyboard input occurs, it crashes. Running the .XEX directly without booting it from a DOS disk works as you'd expect, but of course you can't load or save files to disk

 

What do you mean by use the .xex directly? Doesn't the computer have to boot somehow? If there isn't boot code in the xex file, then it has to be somewhere else. But then, how would that be "directly" using the xex file? I'm asking because I seem to be missing a key step here somewhere. I am interested in this new version of Action too.

[+DrVenkman]

 

What do you mean by use the .xex directly? Doesn't the computer have to boot somehow? If there isn't boot code in the xex file, then it has to be somewhere else. But then, how would that be "directly" using the xex file? I'm asking because I seem to be missing a key step here somewhere. I am interested in this new version of Action too.

 

In most emulators, there is an option to "Load executable ..." or something like that. It opens a dialog, you select the .xex file you want and it runs. Many carts, for instance, have been hacked into .xex files you can run. If you use an SIO2PC / SIO2USB device, your peripheral emulator (I used SIO2OSX or AspeQt) can do the same. You select the file, reboot the Atari hardware and it boots from the .xex file on your PC, Mac or Linux box. Easy peasy.

The problem is the .xex version of Action! doesn't seem to have any kind of DOS built in. When you boot that file, you get Action! but without disk handler you get when you boot DOS. So it's not really usable for anything unless you want to just type in code snippets to play with.

[fujidude]

Ahh. I get ya. Yes in that case the "boot" is actually taken care of by the emulator in that it simply parses the .xex file and does the equivilent of a "binary load (and run)" on it.

 

So apparently, it would seem there is a conflict in memory usage between this new Action! and any DOS it has been tried under so far.