So include the Stork version?
Then we are complete with the versions...
Jump to content
Posted Sun Feb 8, 2015 5:32 PM
Posted Sun Feb 8, 2015 6:03 PM
Edited by JAC!, Sun Feb 8, 2015 6:09 PM.
Posted Sun Feb 8, 2015 6:49 PM
Posted Sun Feb 8, 2015 7:50 PM
bankmsk equ %1001 ;Only bit 3 and 0 are relevant .if cartridge_type = 15 ;OSS one chip 16 KB cartridge ebank equ 3 ;Editor bank, was 1 in original source lbank equ 0 ;Library bank cbank equ 9 ;Compiler bank .else .error "Unsupported cartridge type ", cartridge_type, ". Use 15 or 43." .endif .align el+$0fff,$00 ; Fill with empty bytes instead of $ff. org el+$0fff .byte ebank & bankmsk ; Bank identifier at end of bank.Et voila:
icl "SCREEN.MAC.asm" .local compiler ; Main bank part of the compiler icl "compiler/LEXICON.asm" .endl icl "MAIN.MSC.asm" icl "MAIN.BNK.asm" mainend .align ml+$08d8,$00 ; Fill with empty bytes instead of $ff org ml+$08d8 .local editor ;Main bank part of the editor icl "editor/EDIT.FND.asm" icl "editor/EDIT.SUB.asm" icl "editor/EDIT.TAB.asm" .endl editend .align ml+$0a80,$00 ; Fill with empty bytes instead of $ff. org ml+$0a80 icl "AMPL.SEG.asm"
Edited by JAC!, Sun Feb 8, 2015 7:51 PM.
Posted Sun Feb 8, 2015 7:56 PM
Wow! Sleepless in Germany...
Posted Sun Feb 8, 2015 8:11 PM
As you said future! This is the beginning of a new Atari age and we all share it. The future is now.
Rock and Roll!
let the good times roll!
Posted Sun Feb 8, 2015 10:02 PM
What about floating point numbers? Maybe as an option, I know it was left out to keep the action code optimised, but maybe there's a way to write a custom OS routine to do FP numbers?
Posted Mon Feb 9, 2015 11:48 AM
I think floating point is left difficult to encourage you not to use it. j/k
It could be a little easier to use. Using the FP routines from assembler or Action isn't bad to the point of being unusable. I did a couple of programs that used the routines when translating a BASIC program to Action. I think at least one was from one of the Compute Books ~Book Two of Atari Programming, Point Set Graphics.
Much of the need for FP would be eliminated easier by having something like a long integer and would probably be easier to implement.
Posted Mon Feb 9, 2015 12:04 PM
As a scientist I am 100 % with you. This goes even back to a dream a have: Fortran 77/90 for Atari...
Well, let's give the people some time for developing.
My blueprint is as follows:
(Atari Basic Ver. C (source code we already have), TurboBasic XL (source code is in the making), Basic XL (source code we already have), Basic XE (), Altirra Basic (source code we already have), MS Basic I and II(?) to finally build the last Atari Super Basic on an open source base.
Then(!) there has to be the FP integrated: here is my plan: OS source listing we already have, plus the Atari Calculator routines:
please go up to the end of the page, plus the fast ones from Charles Marslett. Goal: Poke "precision,2" for 2 digits, up to 15 or 16...
Action! is already in the making.
Mac/65 or a Super Assembler. Well, that would be hard, MADS we do have, but we will see.
We live in interesting times... :-)
Posted Mon Feb 9, 2015 12:29 PM
Just located one of my most-hated bugs:
; .BYTE 0,0,0,0,0,0,0,0 ; 7
Strig() reads the hardware register instead of the shadow register. This made my game totally uncontrollable because Action! is so fast, the bouncing of the mechanical trigger is visible.injj
BTW: Great work!
Thanks for pointing this out because it makes it possible to do a work around if it becomes a problem. It probably should be left as is in the official cartridge just in case someone needs it that fast or has already adapted their program to account for it. It's pretty easy to just read the debounced shadow register under program control.
Posted Wed Feb 11, 2015 4:43 PM
Edited by JAC!, Wed Feb 11, 2015 4:44 PM.
Posted Thu Feb 12, 2015 11:53 AM
I see it the other way around. All other functions use the shadow registers, only this only bails out with no reason.
Edited by Kr0tki, Thu Feb 12, 2015 11:53 AM.
Posted Thu Feb 12, 2015 2:44 PM
99% of problems are just solved by documenting the behavior. As KrOtki points out, set GRACTL. As JAC points out, could be fixed in cart which in no way inhibits your ability to directly read the hardware register. I'm not sure about the runtime packages because at least one is a directly copy of the cart routines, all can be patched or edited to do what you actually want.
There's no way of knowing if there was a piece of hardware that actually needs the routine as written. It is probably inconsequential at this stage, something like Mr. Parker used an 800 with a Corvus HD that needed it???
For any substantial Action! program, they all end up being a compile from disk. Pretty easy to patch the runtime to make sure it is doing what you intended. i.e.
Posted Thu Feb 12, 2015 3:02 PM
The name of the function is the name of the shadow register.
Atari Basic (which is the defining base for all these function and their names) uses shadow registers for everything.
The Action! joystick routines published in the OSS Action! toolkit use shadow registers.
The other available 3rd party runtimes all use shadow registers for everything.
Nobody presses a fire button more than 50 times a second.
I personally spent hours trying to find out why a simple 4 line program transferred from Atari Basic didn't work.
That are enough reasons for me personally to consider this a fix.
Edited by JAC!, Thu Feb 12, 2015 3:08 PM.
Posted Thu Feb 12, 2015 6:57 PM
Right with the one possible exception of the runtime that just copies the routines directly from the cart. I can't recall the name of the programmer but I think you can find it in the umich Atari 8 bit archive if you need to know his name for some reason. This would of course means it copied the bug.
AFAIK, not many programmers<0?> used that technique/RT as people mostly used the Jeff Reister PD RT or commercial RT package.
I may have to revisit some of my odd hacks. I recall/still have the prototype of a single joystick port EPROM programmer I made. I used three 74ls164 to convert bit wise data into a byte and address. Pretty sure I had huge problems with denouncing the circuit. I think I used the 4 bits of port to handle clock, control, and data, and maybe Strig to read it back. Odd because it was digital but the noise introduced by hard switching and RFI blocking components on the J/S was enough to glitch the circuit.
Posted Mon Feb 16, 2015 5:57 PM
.byte <??en56 .byte <en3 .byte 0,0 ; 2 ; ; .BYTE 0,0,0,0,0,0,0,0,0,0 ; .BYTE 0,0,0,0,0,0,0,0,0 ; 17 ??en6 .byte 6,'PrintF',200 .word libio.prtf ; #117 .byte 6,17,12,12,12,12,12 ; .byte <??en61 .byte <??en35 .byte 0 ; 1 .byte <??en39There's even a hidden 3rd copyright notice encoded:
; ; .BYTE 0,0,0,0,0,0,0,0,0,0 ; 10 ; (c)1983ACS in internal char. qcode ;copyright .byte 8,99,9,17,25,24,19,33,35,51If this table is every moved one byte in either direction, it will probably go to hell with no way of knowing whether another valid sequence exists at all.
Edited by JAC!, Mon Feb 16, 2015 5:58 PM.
Posted Mon Feb 16, 2015 6:40 PM
Posted Mon Feb 16, 2015 7:00 PM
Hmmm, crashes atari800 3.0.0 when you try to compile.
PROC MAIN() PRINTE("HELLO WORLD") RETURN
Not that you should lose any sleep over it, you're doing amazing work!
Posted Mon Feb 16, 2015 7:58 PM
Edited by JAC!, Mon Feb 16, 2015 7:58 PM.
Posted Tue Feb 17, 2015 4:04 AM
Just an idea - maybe it would be possible to despaghetti the code so it takes more banks (e.g. 32 or 64KiB), but is devoid of these messy byte saving techiniques
Posted Tue Feb 17, 2015 6:08 AM
; RstBank() ; --------- rstbank .proc .if .def bank php pha tya ldy curbank rbank1 sta bank,y tay pla plp .endif init rtsBut they allow me to gradually remove the parts will not be required anymore in future. OSS bank switching and ROM protection belong to this.
;SPLInit .proc ; init compiler RAM ;TODO This should be a subroutine .if .def ramzap .if ramzap jsr editmain.fmcmd.zap4 .else nop nop nop .endif .endifMy plan is to have a slightly modified OSS compatible version that can replace the original. Given the 27 free bytes, that will include only simple things like case-insensitive search (which I once did as patch), less anyoing "BEEEEEEEEEEEEEEEEEEEEEEP" and the mentioned runtime lib fixes.
0 members, 0 guests, 0 anonymous users