Goochman Posted April 2, 2003 Share Posted April 2, 2003 This is the only game I really finished - All basic - Guess what series influenced me at the time Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted April 2, 2003 Share Posted April 2, 2003 Ultima? It started out in the land of Basic, as well. Quote Link to comment Share on other sites More sharing options...
Shannon Posted April 2, 2003 Share Posted April 2, 2003 Anyone knows the "Turbo BASIC" ? This was released in a German magazine in 1985 or 86 and was far better than ATARI BASIC , was used for many programs. The "Keypress"-problem was easy to solve here - just write GET X , and the computer waits until you press a key. And then X has the number of the key pressed. Another advantage of Turbo BASIC is,that it has more free RAM with a disk-drive (34000+ bytes) and is faster. it´s easy to find today. Thimo I don't remember messing with Turbo Basic too much, but I always thought that Basic XL/XE were cool (fantastic languages), and ACTION although I never bothered to program in ACTION. Most of my BBS programming days were in Basic XL/XE. It drove me nuts working on BBS source code in regular basic with it's limit on the number of variables you can create. Basic XL/XE had ways around that. Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted April 2, 2003 Share Posted April 2, 2003 ...so did regular Atari Basic (arrays and matrixes) Quote Link to comment Share on other sites More sharing options...
Shannon Posted April 2, 2003 Share Posted April 2, 2003 No, that shouldn't matter (at least I don't see how it would)...since Basic would still only have the Ram available to it. I think that I missed something in there Just a guess here (it's been years). But don't you have to do some other pokes so the screen handler knows where the new screen is located? Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted April 2, 2003 Share Posted April 2, 2003 Possibly... The ones that I remember are 88/89 (for screen writes) and DL+4/DL+5 (so the list is pointing at the right area to display) Quote Link to comment Share on other sites More sharing options...
ZylonBane Posted April 2, 2003 Share Posted April 2, 2003 Maybe the emu does have some problem with string handling. Umm, you know darn well that emulators don't know about anything above the hardware level. And a big "D'oh" on me for that trailing semicolon. Too much modern programming on the brain. Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted April 2, 2003 Share Posted April 2, 2003 lol You could have looked at the sentance right after that one. Quote Link to comment Share on other sites More sharing options...
Shannon Posted April 2, 2003 Share Posted April 2, 2003 Possibly...The ones that I remember are 88/89 (for screen writes) and DL+4/DL+5 (so the list is pointing at the right area to display) Like I said my memory is very fuzzy but I vaguely remembering the screen handler having certain addresses that it used to control things like the action characters... (tab, ctrl-del, scrolling, clr, etc) and if you didn't poke them properly the screen would act funky like that when putting it in a variable. Just a side note, one of the bad thing about putting a screen in a dimensioned string like that is you cannot just for example say A$(5)="A" and expect the letter A to show up. Didn't Atari's internal character set work differently. Again it's been ages. Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted April 2, 2003 Share Posted April 2, 2003 Yep...you would need to use the POKE values instead. IIRC 32-95 move down 32, 0-31 move up 64, and 96-127 remain where they are...so lower-case characters would be safe ("hello" would look the same if it is PRINTed or POKEd). Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted April 2, 2003 Share Posted April 2, 2003 BTW here's a little time-saver for those of you typing in programs in an emulator... In the emulator, set up the Hard Drive folders by typing alt-h and picking a folder. Next, highlight and copy the online program and paste it into Notepad (don't use Wordpad)...and tack this character to the end of each line › (it looks like >, but really it's character 155...which is the Atari's return character). Save the file to the hard drive folder using the Atari rules for filenames (i.e. filename.ext). Now you can load it into the emulator just by typing ENTER"H:filename.ext" Pretty slick, right? If you have a scanner and a program to convert the pictures to text, you can do the same with magazine type-ins Quote Link to comment Share on other sites More sharing options...
TMR Posted April 2, 2003 Share Posted April 2, 2003 Just compare the Atari Basic with the C64 Basic on Cold starts. Atari has 37902 Free and C64 has -26627 So if im right, Atari has more Basic memory. No, welcome to the world of bugged BASIC commands... =-) (The FRE command is messed up on the C64, you have to subtract it from another value to work out how much memory there actually is available. From dead, the power up message is right and there are 38911 bytes allocated to BASIC... =-) Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted April 2, 2003 Share Posted April 2, 2003 Well...we'll have to give C64 the edge then (by 1k anyway). But it would pass back to Atari if Dos wasn't needed in memory...since the Commodore drives have that built-in. So between cassette systems, Atari would edge out C64 by 1k. Quote Link to comment Share on other sites More sharing options...
TMR Posted April 2, 2003 Share Posted April 2, 2003 Well...we'll have to give C64 the edge then (by 1k anyway). But it would pass back to Atari if Dos wasn't needed in memory...since the Commodore drives have that built-in. So between cassette systems, Atari would edge out C64 by 1k. Only for pure BASIC, a machine code program or data of some form for either BASIC or machine code can still load under the ROM at $a000 and even as far as $cfff. Loading under the VIC-II at $d000 requires custom loaders (at least from disk, i'm 99% sure tape is the same). Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted April 2, 2003 Share Posted April 2, 2003 Apples to oranges Heck, there are 8-bits that have 4meg ram upgrades that can take advantage of memory stores that are unavailable to standard Basic. I imagine that the same can be said about the C= Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted April 2, 2003 Share Posted April 2, 2003 i still write all my PC conversion tools in turbo basic xl, run them in atiar800win + "h:" handler to get the pc harddisc directly... all gfx etc done on pc and then converted in the emulator for atari usages... why? because i do not want to start big visual studio stuff just to convert gfx, sprites etc... and i want to have directly a "WYSIWYG" atari feeling and turbo basic is perfect... even using GW basic, java etc does not speed things up... our coders have a "atari display" emulation module in java so they can check directly their effects in java and then convert later the code into 6502 assembler... but for me it does not make sense as i would have to learn java... (and i hate object orientated languages... ) maybe i am too retro... heaven/taquart Quote Link to comment Share on other sites More sharing options...
Shawn Jefferson Posted April 2, 2003 Share Posted April 2, 2003 How about this one...DIM A$(2048):A$=CHR$(0):A$(2048)=A$:A$(2)=A$ That would create a 2k block zeroed out ready for use in a P/M routine Doesn't a PM area need to be aligned to a 2k boundary? BASIC would move the string around as more memory is used and you may not get an aligned 2048 byte string? Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted April 2, 2003 Share Posted April 2, 2003 No...there are two ways of insuring that the area is placed just after a boundry (I explained one of them in the post with the TEMP$ variables...the other one involves POKEs to the variable table to point it to the right memory area). Once a string is DIMensioned in Atari Basic, it stays put...even if it is empty Using the method in the followup program, the important part is to not have any other variables being defined while you are creating the TEMP$'s and P/M$'s (otherwise, you would lose your point of reference). As it is...TEMP2$ (the one that takes up the slack below the nearest boundry) has a very slim chance of being DIMensioned at zero bytes (causing an error). You might need to insert a TRAP statement...but I've never had to. So TEMP1$ finds out what memory location you are at, and TEMP2$ fills up the memory to the boundry, and the rest fall right into place automatically. Quote Link to comment Share on other sites More sharing options...
Shannon Posted April 3, 2003 Share Posted April 3, 2003 Yeah I knew there was a catch to using strings for P/M space but couldn't remember exactly what it was. Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted April 3, 2003 Share Posted April 3, 2003 Oops... Looks like I screwed the pooch a bit on that method too. I forgot to subtract the address FROM a multiple of the boundries Plus, a length of 1 byte would also need to be subtracted (i.e. the length of TEMP1$). It's probably also better if it is all done on a single line, so I shortened the bariable names). So here's a revised program...you can cut and paste this into Notepad to take advantage of the hard drive function in Atari800Win...don't type the trailing character on each line if you are doing it manually... 10 DIM T1$(1),T2$((INT(ADR(T1$)/1024)+1)*1024-ADR(T1$)-1),PM$(384),M$(128),P0$(128),P1$(128),P2$(128),P3$(128)› 20 PM$(1)=CHR$(0):PM$(384)=PM$:PM$(2)=PM$› 30 M$=PM$:P0$=PM$:P1$=PM$:P2$=PM$:P3$=PM$› 40 POKE 54279, ADR(PM$)/256: POKE 53277, 3: POKE 559,46› (Remember not to type the › characters if you are keying it in by hand) You could also use single-line DMA by doubling all the values...i.e... 10 DIM T1$(1),T2$((INT(ADR(T1$)/2048)+1)*2048-ADR(T1$)-1),PM$(768),M$(256),P0$(256),P1$(256),P2$(256),P3$(256)› ...and changing the last statement to POKE 559,62 Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted April 3, 2003 Share Posted April 3, 2003 but atari basic + PM sux... as you can not move sprites fast enough in y-directions... so i would prefer turbo basic or an assembler routine for ataribasic. turbo masic has "move src,dest, amount" command which you need to move players around... or you take this assembler routine in 1536 = $600 ;a=usr(1536,data,dest,resolution) org $600 pla pla sta len pla sta dest+1 pla sta dest pla sta data+1 pla sta data ldy #0 ldx len loop lda (data),y sta (dest),y iny dex bpl loop rts cheers, karolj Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.