Action! Source Code Action! Source Code

[FlorianD]

@luckybug: i mean the documentation of the "new" release/version after all bugs are debugged, extended memory use is included, CASE statement is in and ...else... . Nice docs for "Version 3.6+" and onwards.

[+JAC!]

Had an idea how to protect the fragile fall-thoughs in the context of the re-work. This macro supplements the "falls into" comments now, enforcing the binary sequence for the fall-though is kept.

.macro m_assert_next
 .if :0 <> 1
  .error "Wrong number of arguments"
 .endif
 .if * <> :1
  .error "Fall-though to next label broken. Next label at ", *, " must be ", ":1" 
 .endif
.endm
 
 

deltop .proc ; DelTop()
lda vars.delbuf+4
ldx vars.delbuf+5
sta delnxt
stx delnxt+1
m_assert_next delend ; falls into delend
.endp
 
delend .proc ; DelEnd(ptr)
cmp #<vars.delbuf
bne de1
cpx #>vars.delbuf
de1 rts 
.endp
 

Tested with the editor sources and works fine. Next is adding it in all remaining locations.

 

[flashjazzcat]

Nice!

[UNIXcoffee928]

... nice thing about the refactoring I'm doing is that any hardware configuration can be supported to the best extend possible. And there will be parallel builds to support all of that, so you can run it on an unexpanded 800 as well as on a 1 MB XE. All with the planned enhancements...

 

Thank you, so much, for all of your work on this project! The planning & work that you are doing is really spectacular. I'm really glad that someone with your level of skill, planning, and determination has taken on this monumental task. You are exactly the right guy for this job! I'm really looking forward to seeing this project develop, over time. Thanks for all of the updates, it's really interesting to read about all of the steps that you are taking to tackle all of the tricky issues that you're running across, as you go along. Thanks!

[+Larry]

Hi JAC!-

 

I was able to take my hard drive backup program in Action! and successfully enter it into your rom and then compile it correctly. It ran successfully, backing up my MyIDE-II HD to an APE HD image. The only issue that I found was that it frequently missed keystrokes trying to switch from the Editor to Monitor and such. Sometimes, I needed to press the key several times to get it to respond. That might be an issue with the MyIDE-II, but I don't think so since it doesn't do that with other rom or xex files. I also got "screen garbage" displayed when moving from the Editor <==> Compiler, but it was brief and was cleared and replaced with the proper screen info.

 

I hope you can fix the multiplication/division bug(s). On this run, the elapsed time came out OK, but about 50% of the time (in the past), the math is crazy for the elapsed time jiffy counters. For instance, a normal time for the program to back up 12,000 DD sectors is about 13 minutes, but I've had it tell me the elapsed time was 25 seconds and the like.

 

You're sure off to a great start!

 

-Larry

[Alfred]

Division isn't so much bugged as not available for CARD values. If you stick to INT I think it's fine. If you need division for CARD variables, you have to roll your own.

[+Larry]

Thanks. I'll take a look at that part of the program, but I have kept all the values under +32767, and I don't see why it would work properly part of the time if my assignments are incorrect. (?)

 

(I set it up according to the table on page 63 of the (loose-leaf) manual.)

 

-Larry

[+JAC!]

@Larry: Sounds like you used the first XEX version, right? That one was broken. Wasn't there a way to remove attachments?
Could you send my your Action! source for testing?

Edited February 20, 2015 by JAC!

[MrMartian]

While you're looking, any ideas on why Action doesn't get along with QUICKED?

[flashjazzcat]

I read somewhere that Action! provides its own screen accelerator(?).

[+JAC!]

While you're looking, any ideas on why Action doesn't get along with QUICKED?

What is QUICKED and what's the problem?

 

I read somewhere that Action! provides its own screen accelerator(?).

In fact it uses the standard OS PUTCHR routine from the E: handler. Never thought it could be so fast.

One idea that I have is to include the HyperE handler in ACTION! itself. Did anyone every use ACTION! with an XEP 80 driver btw.?

In addition you have the option to turn the screen (DMA) off during compilation to speed things up.

Thinking about it, that is probably the reason why there is this (untimately commented out) feature of flashing the border color while loading source files.

With screen turned on you get "INCLUDE D1:XYZ" and see the progress. With the screen turned off you wouldn't have any clue.

[drac030]

QUICKED is the screen accelerator distributed with SDX. It takes over the entry in HATABS, replaces the PUT vector in the vector table, and also replaces the PUT vector in the IOCB#0. Action! (as, AFAIK, the only one program) is reported to not cooperate well with it, it is not completely clear, why.

[+JAC!]

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.

[+Larry]

@Larry: Sounds like you used the first XEX version, right? That one was broken. Wasn't there a way to remove attachments?

Could you send my your Action! source for testing?

 

I'm reasonably sure that I used the second version that you uploaded. It was a zipped single CAR file that I stripped of the first 16 bytes. I've sent you an ATR that has the files that I used, including the source code for my HD backup (sector copier).

 

I now believe that the screen "garbage" is probably not due to your rom version. But I've looked at several other programs and do not see the issue with the keystrokes. I guess if you put it into a real cartridge or Altirra and it uses the keystrokes smoothly, then that will mean it is tied to the MyIDE-II cart. BTW, I'm not saying that your version had any part of the math issue -- that is an old problem, and I've read about it other places in addition to my experiences. But again, your version compiled and executed the ACT code perfectly.

 

-Larry

[Alfred]

As I recall, the Action! editor didn't work properly with a real XEP80. The editor doesn't work properly with the Altirra XEP80 driver either. The characters you type don't show, in addition to there being no cursor.

[fujidude]

Correct, Action! and XEP80 did not work together. I remember this from when I was using the real hardware.

[UNIXcoffee928]

As I recall, the Action! editor didn't work properly with a real XEP80. The editor doesn't work properly with the Altirra XEP80 driver either. The characters you type don't show, in addition to there being no cursor.

As I had mentioned, in the Bit3 Fullview-80 thread, Action! was advertised as having full compatibility with the Bit3 "Fullview-80" 80 column card. I am unsure as to the method/magic that they used, but, please do be careful to not accidentally disable this functionality, while hacking at it, as it's the main reason why I want to use Action!, in the first place. Thanks!

[Alfred]

I'm not familiar with the Bit3, but if it did work with Action! then it must have used the OS screen variables. While Action! does use the normal E: device for a lot of things, it draws the edit screen to memory directly. Things like the XEP80 don't work in that case because they don't offer direct memory access.

[flashjazzcat]

This seems to contradict the previous assertion that it uses the E: putchar routine throughout. So which is it?

[+JAC!]

In fact it's a combination of both. There's specialized routine for printing strings, that is used together with most other stuff routed through E:'s PUTBYTE and that are compatible with each other.

Edited February 22, 2015 by JAC!

[flashjazzcat]

So do certain parts write directly to the frame buffer, bypassing CIO?

[+JAC!]

So far I isolated 3 part that do this:

- editor.cmd.move.move_lines: scrolling up down

- mainio.putstr: write single line (up to 240 chars) with clipping at rmargin

- all the cursor handling (blinking, restoring)

[flashjazzcat]

Interesting. Various sources seemed to imply that the editor display refresh went through the CIO, but I'm not surprised to see that it doesn't. I'm quite surprised the E: vectors are used at all, then, if they're not used universally, and since compatibility with CIO-based display drivers is already broken.

 

I suppose an interesting optimisation would be to do what the APT FDISK does: use a fast, direct-write driver for 40 column mode, and look for the RAWCON symbol under SDX and vector through the S_VBXE or RC_GR8 handler tables if found, adjusting screen bounds accordingly. This would provide a nice hardware or software 80 column display under that OS.

[ricortes]

I'm probably the only guy who used the dual window display to cut and paste routines from one program to another. IIRC that function/feature broke at least some of the software 80 column drivers.

 

I'm firmly in the large programs on an Atari and the I/O becomes a bottleneck camp. Remember the ROTO thread where everything had to be moved to and compiled from disk. This limits just how large a program you can develop even with the include function. I recall including Micro Illustrator files as byte arrays and the files were ~24k each. There are a number of work arounds, it was just the way I wanted to do it.

 

So in that light, a real significant changes to the cartridge <other then the ability to change the defaults like buzzer and margins> would be text editor buffer in banked. I think it would only require switching to a bank on entry to the editor and flip flopping banks while generating code when it gets to $4000. The way it works now, with code space and binary growing with the program, eventually filling memory forces you to go to disk, even ramdisk, sooner then you should. You should be able to load at least 16k of code before you start to need saving to disk. It would let you develop programs starting at $2000 or on top of R: Handler space with everything memory resident.

 

I'm not sure how it should be implemented. Something like ~optional use banked for editor with bank order variable. We have all these 256k XLs and 320k XEs and we use them for ramdisks and demos. It would be nice to have Action a native programming environment on the Atari that took advantage of expanded memory. 16k/single bank would probably be enough.

[+JAC!]

Changes of the past 3 days.

 

 

Right now I'm in the process of replacing numeric constants with symbolic constants all over the place (cio_command, cio_mode, opcodes - the latter are at about 40%). Next then is replacing the ".byte 4, 'Test'" string definitions with the new macro.

 

Pitty my vacation is over tomorrow and I have to get back to work :-)

 

>I'm firmly in the large programs on an Atari and the I/O becomes a bottleneck camp.

I also see that. But considering that I even did it on my Amiga that way, my first attempt would be to use the underlying DOS's RAMDISK, keeping the handling of the actual extended RAM to the proper drivers.

Edited February 22, 2015 by JAC!