rsh

Thanks for response....It's not that, this program has long been too big for the editor. Can only be compiled from disk. Reboot seems to be a common requirement as sometimes it will compile and run other times it compiles and crashes on run. I haven't figured it all out yet why it's happening with local... It appears the compiled code with cartridge routines vs runtime routines do things differently. I'm stuck with doing things like shrinking the runtime and variable crunching to get around it.

It's on my list !!! I'm currently working on a large Action! game... I have couple of hurdles left to figure out with Action! But, I think the mouse is doable and will be a lot faster, with some added features such as cut/paste/dup can move by color clock instead of by byte and will be able to move behind or in front of existing colored screen areas.

BrushUp v5.8 (attached!) ... Two fixes, corrected since 5.7. From: BUREADME.BXE on Brushupv58.atr Bug Fix/New from v5.7 * Hex offset toggle value was incorrectly showing E value twice, Now shows D value correctly. FIX * Dup/Cut/Paste was corrupted when Hex offset toggle was on. Offset now disabled when in use. FIX -- end -- BrushupV58.atr

Sweet thank you. I will definitely use it. I working on game now and using runtime lib seems to eat the local symbol space up during compile. I don't understand this cause all the procedures are assembly with =* in them. Once local filled your hosed. Global you can adjust but not local. Any insight on what Action it's doing?

Attached is Disk: BrushupV57.atr

BrushUp v5.7 (attached!) ... Fixed a dup/cut range select bug in v5.6 that I caused doh!. Fixed some other things bugging me. The palette will no longer flicker in color boxes and Esc/left arrow out of Edit Menu did not reset the draw mode icon at top of screen when it put you back in draw mode. hopefully, no more major bugs.. This should be the most stable and clean version. From: BUREADME.BXE on Brushupv57.atrBrushupV57.atr Bug Fix/New from v5.6 * Palette no longer flickers on the color boxes. However, does require a DMA flash between moving of color picker. A nice trade off. FIX * Attract Mode disabled now when using the palette. NEW * Esc or Left arrow out of Edit menu could show wrong tool on on edit screen. FIX * Fix Dup/Cut select range bug introduced in v5.6 FIX

BrushUp v5.6 (attached!) ... The new moving of the draw objects <with joystick only> and X/Y<space bar> ON feature. Did not work correctly in all graphics modes. And fixed a potential out of bounds crash with this option on as well. Affected pre-drawn objects when using one of these: Quick Key K: Line connect Draw Tool Keys Ctrl+R: Rectangle Ctrl+C: Circle Ctrl+T: Triangle Ctrl+D: Diamond Ctrl+F: Diamond2 Ctrl+H: Hexagon Ctrl+A: Angles L/R Ctrl+S: Star Ctrl+Z: Trapazoid Ctrl+K: Corners From: BUREADME.BXE on Brushupv56.atr Bug Fix/New from v5.5 * Moving of draw tool object with X/Y<space> on did not work 100% in all Graphics modes and for all tool objects. FIX * Out of range crash could also occur moving tool object shape to edges of screen. FIX FYI: Excessive moving at edge of screen in the same direction may distort the original object shape. BrushupV56.atr

@_The Doctor__ Thanks DOC! ... FYI I tested this out on altirra 4.10 and real hardware (130xe) and works fantastic!!!! Now I'm working on stupid DOS eating gobs of memory. I think I figured it out, but need to reorg what I'm doing for DOS usage. So far, I found DOS2.0S uses the least amount of memory (without menu). Most others other suck up a full 5K or implicitly use your extended memory. (I want my code to work on real hardware if possible). Sparta has a cool feature "OSRAM" haven't tried yet (this will not work for Basic XE extension disk) but might work for Action! as long as it doesn't try and use my extended memory. Curious ... have you tried to store Action! procedures in extended memory and run in base code? It has to be possible but tricky since it all needs to be compiled. If we could store code or even compile in extended memory you could write a hella big programs. Sort of like what OSS did with Basic XE (extend mode) that was brilliant. "big is relative here !!!"

It would have to give all graphics 3-15 modes exact pixel location or it's not useful for a drawing tool option or at least for BrushUp. I cheat on Gr.8 but I'm still able provide all 95 brushes to use in 320x192. Another problem is no memory left. I think I can maybe squeeze another 1k out of it... if I do my trick again and that's it. $600 is already being used for the palette. Would need to be super creative to get this to work. The obj would need to be all relocatable for DLI and USR getting x/y coords. In Action! this would be way easier to implement.. which is on my list, I might have to wait until I port over to add mouse support.

BrushUp v5.5 (attached!) ... I broke the Hex offset from showing in v5.4 darn it!!! So I fixed that... and added a new feature I've been wanting to do. You can move a pre-drawn object without changing it's size. This can be done with X/Y toggled on and only with the Joystick. Using the arrow keys will always stretch and size the object being drawn. Once saved to screen it can't be moved <fire/return>. You will need to use cut/paste/duplicate option after that. Affected pre-drawn objects when using one of these: Quick Key K: Line connect Draw Tool Keys Ctrl+R: Rectangle Ctrl+C: Circle Ctrl+T: Triangle Ctrl+D: Diamond Ctrl+F: Diamond2 Ctrl+H: Hexagon Ctrl+A: Angles L/R Ctrl+S: Star Ctrl+Z: Trapazoid Ctrl+K: Corners From: BUREADME.BXE on Brushupv54.atr Bug Fix/New from v5.4 * Hex Offset<o> not showing FIX * Ability to move draw tool objects circle,square,triangle,etc. when XY<space> is on. Note: Only the the joystick can move the object without changing dimensions. The keyboard arrows will always change size dimensions. NEW -- end -- BrushupV55.atr

Still seeing if this is possible. Basic XE uses the memory that one of those mouse routines uses. So, I might have to do something custom. My assembly is not the best at all. I have another example I was going to dive into and hopefully it's relocatable... That would definitely make easier to implement.

For the memory for 800XL... I'm talking with Simius for the Antonio 4MB it does full compy or rambo and I think AXLON (if I have that all that correctly). Cool thing is no soldering, is what I hear.

I was playing around with it in your mode and looks like gr.3-7 seem to work when in the editor.. Which baffles me lol , color picker uses gr. 9 so the players look strange

Ok setting the Ram type to 320K (compy) fixed the problem. So that RAMBO must be 50% compliant with 130XE. I think it only supports CPU mode not both Antic and CPU mode. Which kind of makes sense because all the artifacts your seeing are the player missile graphics rendered by Antic. I've been looking for extended Ram for my 800XL that is full compy/130XE but only the original Novell?? can do it But requires a lot of soldering which I don't want to do. Sorry that's a bummer. Altirra Settings: Base system NTSC 1200XL (320K Compy) Additional devices Host device (H:), Printer (P:) OS firmware Atari 1200XL OS [C5C11546] Mounted images Disk: BrushupV54.atr Cartridge: basxe41.bin [003D3A36]

From altirra settings as: Base system NTSC 1200XL (320K) Additional devices Host device (H:), Printer (P:) OS firmware Atari 1200XL OS [C5C11546] Mounted images Disk: BrushupV54.atr Cartridge: basxe41.bin [003D3A36] I can repeat it so this could be 1200XL quirk. I will play around with it. See if anything makes sense. I will mess with ram type and see if that makes any difference.

c Crazy lol... I'm actually surprised it got that far. I'm assuming after pressing start it looks the same?

That is correct it thinks you are getting all the memory. Show me what the brushup.pic looks like. Does it have lines all in it or totally ripped? Altirra thinks the disk I created is a DOS 2.OS

lol well in the doc I do call it BrushUp XE v5.4 but you need to run the D1:bureadme.bxe file from basic XE (also, this thread is called BrushUp XE v5.1 lol)

Cool 1200XL with RAMBO.. Interesting the 256K RAMBO might be the problem (some are not 100% compy/130XE compatible).. Curious , without my disk just the normal 4.11 extensions what do you see after boot and.... You type extend and then ? fre(1)

Real hardware or Altirra? Altirra Settings: Base system NTSC 800XL (128K) Additional devices Host device (H:), Printer (P:) OS firmware AltirraOS 3.34 for XL/XE/XEGS [8E76DC1B] Mounted images Disk: BrushupV54.atr Cartridge: basxe41.bin [003D3A36]

This program uses 100% of the 128K so a ramdisk will do crazy stuff most likely. Using the disk provided should be fine how are you loading it manually?

I feel your pain... I have all my crap copied a million times just in case one of them crashes.... Good luck on the rebuild... do chkdsk for sure... I see, D:FSEL.COM string in the loader.xex. Is that what you expected? I did download MADS and was able to create an obx file from the loader.asm. Can I just load that into $600 as is... it's about 169 bytes?

BrushUp v5.4 (attached!) ... Well I have to provide this update. The v5.3 woefully broke some stuff. I suggest just not using v5.3 it can lockup on the Circle tool. Almost all were created by the v5.3 updates. Don't worry... The testing department got yelled at for several hours. I was going to fire them all but that would also not leave anyone in development,ops,graphics design,and sound departments FYI... I did test it on Altirra 4.10 and works fine, someone had an issue a while back. From: BUREADME.BXE on Brushupv54.atr Bug Fix/New from v5.3 * Circle Tool was hanging fix * Menu Select Cut:Dup:Fill:Kline fix * Erase toggle messing up tools fix -- end -- BrushupV54.atr

And our Atari's keep running !!

Outstanding!!.... I will have to figure it out, I don't have MADS yet. All I really need is the hex codes of assembly, I can dump that directly into Acition. Really appreciate the help!!!