Jump to content

Photo

Action! Source Code

Action! Source Code

281 replies to this topic

#101 Alfred OFFLINE  

Alfred

    Dragonstomper

  • 557 posts
  • Location:Elmwood, Ontario

Posted Tue Feb 17, 2015 7:17 AM

Moving it under the OS rom is a bad idea since it would no longer work with SpartaDos. Same thing for banks, then it no longer works on stock machines.



#102 danwinslow OFFLINE  

danwinslow

    River Patroller

  • 2,597 posts

Posted Tue Feb 17, 2015 7:45 AM

I agree about OS ram. I'm not so sure about extended banks, it seems that it's more common than not to have access to that today, although I may be mistaken. Since we have carts though that can support huge banking schemes of their own, we might want to target that instead of requiring extended banks on the machine.



#103 flashjazzcat ONLINE  

flashjazzcat

    Quadrunner

  • 14,619 posts
  • Location:United Kingdom

Posted Tue Feb 17, 2015 7:50 AM

Turbo BASIC uses the Shadow RAM, so the idea isn't all that objectionable. SpartaDOS X is able to avoid the Shadow RAM when banked RAM is available, so it's often "six and two threes", so to speak.



#104 fujidude OFFLINE  

fujidude

    Quadrunner

  • 5,217 posts
  • Location:United States of America

Posted Tue Feb 17, 2015 10:05 AM

I agree with flashjazzcat.  For those that have unexpanded XLs that wish to use Sparta and this, they could use the frozen 3.7 version.  For those who are serious enough about programming, doing a RAM upgrade should not be too much of an obstacle.


Edited by fujidude, Tue Feb 17, 2015 10:05 AM.


#105 JAC! OFFLINE  

JAC!

    Stargunner

  • 1,846 posts
  • Always looking for GFX and MSX for my demos
  • Location:Lebach, Germany

Posted Tue Feb 17, 2015 12:46 PM

>Moving it under the OS rom is a bad idea since it would no longer work with SpartaDos. Same thing for banks, then it no longer works on stock machines.
None of the options I've mentioned is exclusive. That 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. And who knows, maybe one day even as separate compiler from the SDX command line (I suppose that's what the SDX people would want to do ... and use The Last Word for editing the source :-) ).

As for cartridges, I would like to avoid replacing the "4k bank switching hell" with an "8k or 16k bank switching hell". Large continous ROMs come at the expense of too much machine RAM not being accessible during DEV & TEST. That's exactly the reason why my current (3 year old) ACTION! project is stuck - out of RAM for source, object code & game data. And for anything beyond 8k in size, Atarimax itself recommends using XEX files for best compatibility. Also an important thing I learned during really using ACTION! on real hardware is that the time to read/writelarge portions of source from any peripherial (even if it's AspecQt) takes the majority of time. Therefore I'd rather optimized that than the loading time/footprint for ACTION! itself by using bank switching again.

Edited by JAC!, Tue Feb 17, 2015 12:50 PM.


#106 JAC! OFFLINE  

JAC!

    Stargunner

  • 1,846 posts
  • Always looking for GFX and MSX for my demos
  • Location:Lebach, Germany

Posted Tue Feb 17, 2015 1:03 PM

Looks like some bytes can be freed by removing the border flashing progress indicator which is technically in (half way), but was seemingly commented out before the release. The background color is restored (to $00), but saving it before hand is missing. The flashing code is replaced by NOPs to keep the memory structure. Maybe he also realized that it wouldn't work correctly, because during I/O the shadow registers are not copied all the time.

bckgrnd equ $04c0 ; background color

during reading
rdbuf .proc ; RdBuf(device)
; INC COLOR4
nop
nop
nop


during writing:
; INC COLOR4 ; let user know we're here
nop
nop
nop

at the end:

lda vars.bckgrnd ; background color
sta color4 ; restore background

Edited by JAC!, Tue Feb 17, 2015 1:04 PM.


#107 Mathy OFFLINE  

Mathy

    River Patroller

  • 2,967 posts
  • Location:Heerlen, NL

Posted Tue Feb 17, 2015 3:27 PM

Hello Peter

 

Why not use more banks inside the cartridge?  The existing Action! cartridge uses one "main" bank (4kB) and three "switching" banks (4kB each).  16kB stuffed into 8kB of address space.  From what I read above, you're not into the bank switching thing, but if you use a 32kB cartridge and divide that into 8 banks of 4kB each, the foot print would be the same (8kB), but you'll have 4 more banks of 4kB for extra functionality.

 

Sincerely

 

Mathy

 

PS or you use 64kB, 4kB in the main bank and 15 banks of 4kB that can be switched in.



#108 DanBoris OFFLINE  

DanBoris

    Stargunner

  • 1,025 posts
  • Location:New Jersey, USA

Posted Tue Feb 17, 2015 4:23 PM

It is very cool to see this source code! Thanks to Alfred and JAC for you work on this. I had an Action! cartridge back in the day and really liked the language. I even did some blog posts here that took a look at the 6502 code that the compiler generated. 



#109 JAC! OFFLINE  

JAC!

    Stargunner

  • 1,846 posts
  • Always looking for GFX and MSX for my demos
  • Location:Lebach, Germany

Posted Tue Feb 17, 2015 4:39 PM

@Mathy:
>Why not use more banks inside the cartridge?
My question is: Why restrict to banks (and their size) of a cartridge at all? There are some many other media, too.
To actually do something useful with Action!, you can safely assume there is DOS, disk and booting. The only reason to put it on cart at all (apart from the copy protection reasons mentioned by Bill Wilkinson iirc), is little faster recovered times if your program killed itself. But I know from my own experience, that you can be sure DOS is also garbage when your program ran beserk and you should rather cold start instead of trashing your working disk. So that doesn't count for me.

Both editor and compiler are actually larger then 4k even in their current state without any improvements:
EDITOR: $8646 - $974A ($1105)
COMPILER: $AD01 - $BF2B ($122B)
The 4k limit is exactly what broke the structure in the original, making it a ton of spaghetti jumping back and forth the banks.

I can create an Atarimax image that unpacks DOS/MyDOS+ACTION! in no time at power-up into RAM and then disables itself.
I can detect extended RAM as buffer for all sources and the runtime lib and the symbol table - leaving tons of RAM plus the 8k cartridge area for the actual code and data. The latter is especially important because it actually very difficult to write a game with DLI,VBI and graphics with that Action! cart in a way that later on actually works (and uses that precious RAM area).

In fact for my project I even implemented a patch that disables the Action! cart during "R" and re-enables it later (if your're lucky and you program didn't crash). My plan is to get rid of all these workarounds imposed by the compromise that was taken for running on an 48k machine.

Edited by JAC!, Tue Feb 17, 2015 4:40 PM.


#110 Mathy OFFLINE  

Mathy

    River Patroller

  • 2,967 posts
  • Location:Heerlen, NL

Posted Tue Feb 17, 2015 5:36 PM

Hello Peter

 

My main concern was foot print.  Those of us living in or not far from Germany, it's easy to find somebody to install a memory expansion in our computers.  But it might not be as easy for those living farther away.  And not everybody might want a memory upgrade.  People owning an 800 (not XL or XE, but plain 800) without Incognito can't even use a $D301 upgrade.  Will the new Action! support Axlon type upgrades?

 

Sincerely

 

Mathy



#111 JAC! OFFLINE  

JAC!

    Stargunner

  • 1,846 posts
  • Always looking for GFX and MSX for my demos
  • Location:Lebach, Germany

Posted Tue Feb 17, 2015 6:41 PM

> And not everybody might want a memory upgrade.
If you really do not want/have an expansion of any kind, the original OSS cart layout is the optimum already. It's what is was designed for.
>Will the new Action! support Axlon type upgrades?
Sure, why not. Couldn't find any reasonable description of the banking scheme ( and Avery's code is sharp and precise without comments :-) ), looks like 0..255 banks of 4k at $C000-$CFFF, banked via $CFFF. The "banked via $CFFF" is the point I'm not sure of and that looks a bit odd to me.

I found a bug caused by my removal of the ROM protection code. There's heavy reuse by using "fall throughs" in the code. That means instead of writing:
 
.proc first
   lda #something
   jsr second
   jmp third
.endp

.proc second
 some code
 rts
.endp

.proc third
 some code
 rts
.endp
You try to save the JSR, JMP and RTS via.
 
.proc first
  lda #something
.endp // No RTS

.proc second
  some code
.endp // No RTS

.proc third
  some code
  rts
.endp
It's obvious that you must design this kind of reuse very carefully and moving "third" before "second" in the source breaks the code.
Here's the original code
;	Close(device)
;	-------------
close	.proc
	.if	.def ramzap

	ldx	#>rom.ml	; note: address must be non-zero to
	stx	arg6		; fake out zero check in XIOstr

	.if	ramzap
	 sta	(arg5),y
	.else	
	 nop	
	 nop	
	.endif	

	.endif

	ldy	#command.close
	bne	input.input1	; unconditional branch
	.endp

input	.proc			; Input(device, str)
	sty	arg6		; Store pointer in <X,Y> in <adr5;adr>
	ldy	#$05
input1	stx	arg5
	ldx	#0
	stx	arg3
; Falls through to xiostr
	.endp


xiostr	.proc			; XIOstr(device,,cmd,aux1,aux2,str)

	asl
..
	lda	(arg5),y
	sta	icblen,x	; size
	beq	print.print1	; return
        jsr     ciov
The "ldx #>rom.ml: stx arg6" was used as a trick to point file spec (typically something like "D1:EXAMPLE.ACT") to an abitrary location in the ROM where the author was sure to not have a zero. Reason: The XIOstr routine assumes ACTION string format (.byte length, .byte "text") and skips CIO if the string is empty. That's correct in 99% percent of all cases, but not with the CLOSE #n command, as it does not require a file spec.

Now that I changed the code to "IF COMMAND = CLOSE THEN SKIP zero check", I could successfully compile my quite large ACTION! project already.

I'd be interested to see of it produces valid & correct output with other peoples sources.

Changes committed:
: Cleanup obsolete and ignore files
: Add comments
: Add support form fix_stsp_pages
: Add support for fix_stsp_pages
: Separate library statement definitions into "LIB.STM.asm"
: Make original ROM handling optional in main banks 8/
: Refactor makefile. Build original CAR, too.Run Altirra with DOS and 16k Cartridge.
: Add fix_stsp_pages switch to increase ST table from 2k to 4k by default
: Add error texts to ideas
: First plain ROM and XEX version

Attached Files


Edited by JAC!, Tue Feb 17, 2015 6:49 PM.


#112 Alfred OFFLINE  

Alfred

    Dragonstomper

  • 557 posts
  • Location:Elmwood, Ontario

Posted Tue Feb 17, 2015 8:07 PM

> And not everybody might want a memory upgrade.
If you really do not want/have an expansion of any kind, the original OSS cart layout is the optimum already. It's what is was designed for.
>Will the new Action! support Axlon type upgrades?
Sure, why not. Couldn't find any reasonable description of the banking scheme ( and Avery's code is sharp and precise without comments :-) ), looks like 0..255 banks of 4k at $C000-$CFFF, banked via $CFFF. The "banked via $CFFF" is the point I'm not sure of and that looks a bit odd to me.

 

Axlon ram is switched by strobing $CFFF with the bank #. The window is $4000-$7FFF same as an XE. My 1Meg 800 has 64 banks.

 

How do you select to restore the default 2K symbol table ? Did you make it a memory option or does one have to rebuild the cartridge ? Doesn't seem to be a very promising start, that the cart was broken just in cleaning up the files.



#113 JAC! OFFLINE  

JAC!

    Stargunner

  • 1,846 posts
  • Always looking for GFX and MSX for my demos
  • Location:Lebach, Germany

Posted Wed Feb 18, 2015 1:45 AM

>Axlon ram is switched by strobing $CFFF with the bank #. The window is $4000-$7FFF same as an XE. My 1Meg 800 has 64 banks.
Ok, than it's even much easier. Does it have an "swiched off" mode/strobe, too?

>How do you select to restore the default 2K symbol table ?
I only changed the default of the setting you can also change via your ACTION! source.

;ENLARGE SYMBOL TABLE FROM DEFAULT 2k (8 PAGES) to 4k (16 pages)
SET $495=16

2k is really not much an all my projects require more, so I increased the default.
Ultimately all options shall be saveable and/or changeable during compilation without re-compiling again.
The "SET $495=16" requires you to compile twice, which is annoying.

> Doesn't seem to be a very promising start, that the cart was broken just in cleaning up the files.
The syntactic cleanup doesn't/didn't break anything. As mentioned above the OSS cart output of the source is 100% the original.
But for the other versions I've started removing unneeded code like the ROM protection to free space.
And this of course is a difficult task where errors can happen, esp. if the original code used side effects like above.
Currently there are 200 bytes free in the 16k ROM now.

Edited by JAC!, Wed Feb 18, 2015 2:06 AM.


#114 pirx OFFLINE  

pirx

    Moonsweeper

  • 457 posts
  • Location:Poland

Posted Wed Feb 18, 2015 2:45 AM

And who knows, maybe one day even as separate compiler from the SDX command line (I suppose that's what the SDX people would want to do ... and use The Last Word for editing the source :-) ).

 

YES!



#115 drac030 OFFLINE  

drac030

    Stargunner

  • 1,836 posts
  • Location:Warszawa, Poland

Posted Wed Feb 18, 2015 4:24 AM

Speaking of SDX and Axlon: in presence of SDX you could consider delegating the task of ext RAM bank switching to SDX jext_on/jext_off calls. This way one does not need to care whether the extension is PORTB or Axlon, and also, in the case of Axlon, would reduce the risk of conflicts between the compiler and other components using the extension (ramdisks, resident drivers, TD Line), which always can occur, because the Axlon controlling register is write-only, so that one cannot just save its current state in order to restore it after use.

#116 JAC! OFFLINE  

JAC!

    Stargunner

  • 1,846 posts
  • Always looking for GFX and MSX for my demos
  • Location:Lebach, Germany

Posted Wed Feb 18, 2015 8:23 AM

Thanks for the hint as I have no experience with SDX yet. In fact I thought about extended memory mainly as using it as RAMDISK for the source and maybe the executable. Once the fixes & features are in, I'll check where the performance during compilation & read/write of the source actually goes.

#117 Alfred OFFLINE  

Alfred

    Dragonstomper

  • 557 posts
  • Location:Elmwood, Ontario

Posted Wed Feb 18, 2015 8:37 AM

By changing the default symbol table size you've made it so that large source files that used to load will no longer fit. I suppose it's arguable which is worse, not being able to load the file vs having to set the size, like you always have had to do previously.

 

I had a comment queued up about your complaint that source files are loaded slowly, because when I use Action! it loads the source files at full binary speed, like Mac/65 does. So I was going to say, wth are you talking about. Then I remembered, the real cart uses text get which is kind of slow, whereas my version doesn't.

 

I realize it's tempting: "2k is really not much an all my projects require more, so I increased the default." but if you're just going to remake Action! so that it works best for your personal setup, then it probably isn't going to be used by very many people. Why not instead make a branch that has your personal preferences and leave the main trunk as the original setup ?

 

Edit: No, there is no "Off" switch to the Axlon. You just strobe $CFFF with zero. There's also a quirk with Axlons, at least some of them. I don't know if it applies to all Axlons or just some models. On mine anyway, which as I said was a one megabyte upgrade, if you strobe $CFFF or (iirc) $FF the bank will switch. I'm not positive but I believe my 288K 800 does -not- bank switch when $FF is strobed. I don't know what the various Axlon compatible upgrades do, if they fixed that behaviour or faithfully copied it.


Edited by Alfred, Wed Feb 18, 2015 8:41 AM.


#118 Alfred OFFLINE  

Alfred

    Dragonstomper

  • 557 posts
  • Location:Elmwood, Ontario

Posted Wed Feb 18, 2015 8:56 AM

Thinking about versions I went back and looked at my copy of Mac/65. The source code that Mike gave me turns out to be for version 1.00. That seems odd. Mike got it from ICD, who you would think would have had the latest version of the code, namely 1.01. Since they didn't, that would imply that the 1.01 rom was just given to them and that Lawrow/OSS never actually turned over the source to that last rom version.

 

I've never used anything but the cartridge 1.01. Does anyone know if there is an actual differnce in functionality between 1.00 and 1.01 or is it likely that it's just some hidden bug fixes. I already have a disassembler listing for the 1.01 cartridge, so I'll run through it and see what they changed.



#119 luckybuck OFFLINE  

luckybuck

    Stargunner

  • Topic Starter
  • 1,062 posts

Posted Wed Feb 18, 2015 9:32 AM

@Alfred

 

1.02 is the latest! Some bugs in the compiler are solved. For short this was a mystery, due to the OSS Newsletter thread I opened here, we now have proof.

 

You can find the 1.02 version:

 

http://www.atarimani...-65_s10965.html

 

here, but that is not the one(!) I got from Stephen. The MD5 checksum is different.

 

The 1.02 is in kingblue...



#120 JAC! OFFLINE  

JAC!

    Stargunner

  • 1,846 posts
  • Always looking for GFX and MSX for my demos
  • Location:Lebach, Germany

Posted Wed Feb 18, 2015 9:51 AM

>Why not instead make a branch that has your personal preferences and leave the main trunk as the original setup ?
No worries and no need for branches. As mentioned above these are currently compile time options (fix_stsp_pages = 1) soley, because there's no way of persisting the options yet. Simply currently my only test file requires it currently.

What I have in mind is to introduce an "OPT" directive similar to the "SET" directive, but with more declarative syntax and immediate effect.
Like "OPT BEEP=NO" or "OPT SYMBOLS=4K".

Edited by JAC!, Wed Feb 18, 2015 9:51 AM.


#121 Alfred OFFLINE  

Alfred

    Dragonstomper

  • 557 posts
  • Location:Elmwood, Ontario

Posted Wed Feb 18, 2015 11:34 AM

 

@Alfred

 

1.02 is the latest! Some bugs in the compiler are solved. For short this was a mystery, due to the OSS Newsletter thread I opened here, we now have proof.

 

You can find the 1.02 version:

 

http://www.atarimani...-65_s10965.html

 

here, but that is not the one(!) I got from Stephen. The MD5 checksum is different.

 

The 1.02 is in kingblue...

 

 

Well that's interesting. The question then is what is in the 1.02 version, and who produced it. Unless it was an Fte edition that he just called 1.02 but was created from the 1.00 source.



#122 FlorianD OFFLINE  

FlorianD

    Star Raider

  • 59 posts

Posted Wed Feb 18, 2015 4:41 PM

this is all truly amazing ...

speechless.

 

Jac!, all the best, carry on with the excellent work. I'll be there when it comes to documentation design and layout, OK?



#123 luckybuck OFFLINE  

luckybuck

    Stargunner

  • Topic Starter
  • 1,062 posts

Posted Wed Feb 18, 2015 5:32 PM

@Alfred: Alfred, I think this is a too important topic to be discussed here. I will make a new topic: "MAC/65 - the final chapter", o. k.?

 

@Florian: already done, just the documentation of the cart is still missing, of course. The manual, as far as know, will be published on the JHV in October.


Edited by luckybuck, Wed Feb 18, 2015 5:33 PM.


#124 Larry OFFLINE  

Larry

    River Patroller

  • 4,112 posts
  • Location:U.S. -- Midwest

Posted Thu Feb 19, 2015 3:45 PM

Hi JAC!-

 

Impressive stuff! 

 

You posted a CAR image of 16400 bytes. I would like to use the rom so that I can try it in the MyIDE-II.  I looked briefly, but didn't find any info on converting a CAR to a ROM, although Atari800... has the ROM to CAR conversion. 

 

Maybe just discard the first 16 bytes of the file?

 

-Larry



#125 JAC! OFFLINE  

JAC!

    Stargunner

  • 1,846 posts
  • Always looking for GFX and MSX for my demos
  • Location:Lebach, Germany

Posted Thu Feb 19, 2015 4:08 PM

>Maybe just discard the first 16 bytes of the file?
Yes, exactly. Once I have the build process automated, all formats will be available for download in parallel.

Edited by JAC!, Thu Feb 19, 2015 4:08 PM.





0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users