Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store

tschak909

Members
 View Profile  See their activity

  • Posts

    6,908

  • Joined

  • Last visited

  • Days Won

    6

 Content Type 

Blog Entries posted by tschak909

  1. tschak909
    I decided one afternoon a couple of days ago, to clear my head from work, and various other projects, to do something else.
     
    I do this from time to time, but what to do? Meh, I'm a hacker. I'll find another hacking project to wipe my brain clean.
     
    I had always found FORTH to be an elegant language, if a bit steep to entry; especially given FORTH's extreme emphasis on efficiency and the alignment of the language entirely to that end. It looks and feels literally like Yoda's brain.
     
    Add these numbers together on the stack, I do. 4 4 + .. yes, that adds 4 and 4 together, and puts them on the stack. It doesn't do anything else, because I haven't told it to do anything else. It merely prints 'ok' .. letting me know i had done so.. Would I type a period '.', or had added a period to the statement, it would have printed the number 8.
     
    Yeah... Odd. Especially if you come from one of the many languages espoused by ALGOL (C, Pascal, Fortran, BASIC, Python, Shell Script). But it does have many advantages:
     
    Grammatically, the language itself is very simple, a line in forth is merely a set of words, terminated by a <RETURN>
     
    What words? you can ask for a list by typing VLIST at the prompt.
     
    Need more words? you can add more words using the colon : word. end it with a semicolon.
     

    : HELLOWORLD ." HELLO WORLD! " CR ;
     
    now I can just type HELLOWORLD and have it output:
     

    HELLO WORLD ok
     
    Couple this, with a variety of words that can easily access the hardware below, coupled with an assembler which can be used to quickly jump into 6502 assembler at any point, and it becomes evident how powerful FORTH really is. I literally see it as an interpreted language with a speed approaching native assembler (which is possible because of the sheer simplicity of the interpreter, coupled with the fact that the stack is used as efficiently as possible.)
     
    So I put up with a degree of ...awkwardness in my own head, trying to shift to its unique way of doing things.
     
    But why this FIG-FORTH?
     
    This particular FIG-FORTH is literally a transliteration of Bill Ragsdale's 6502 FIG FORTH environment, with the relevant patching to make it work with the ATARI editor console, and with the appropriate patching to make it also work with CIO calls to the disk. This particularly makes the disk one big scratch pad, divided into blocks (128 bytes each, corresponding to a sector), and 8 of these blocks, forming together to produce one SCREEN (1024 bytes, which, is set up as 16 lines of 64 characters each.
     
    This FIG-FORTH provides two commands LOAD, and SAVE (and their corresponding cassette equivalents, CLOAD, and CSAVE), to load and save the FORTH environment appropriately. LOAD takes one parameter, the screen # to load, and feeds it into the FORTH interpreter, line by line, as if it had been typed in by hand, and the resulting definitions are now present. SAVE on the other hand, saves the ENTIRE FORTH environment, the interpreter, and its compiled definitions to disk, creating a bootable FORTH environment with all the words that are active at the time the SAVE took place, making this environment very nice for game development. (IMHO)
     
    You may be wondering, does this APX Fig Forth provide graphics etc functions? It does, but in the end, I won't be using them. Why? Because FORTH provides direct access to the hardware below, coupled with an assembler, I'll be able to make my own words specific to what I need, so in the end, I have what I need.
     
    So what's first?
     
    In essence, the APX Fig-FORTH on the disk is all there, but a few of the screens are corrupted slightly, and they need to be fixed. Well, unfortunately, a couple of the affected screens are literally inside the vocabulary that comprise the EDITOR. so what do I need to do? I need to type in the code for the words that comprise the editor, so I can recreate the screens on the disk. Yes, it's a chicken and egg issue., But. as I have implied before, anything on a screen can be typed directly into FORTH, and this is how I will get the editor back so I can edit the screens.
     
    I am using the dump of the screens that Carsten Strotmann (aka cas here on the forums) put here: http://atariwiki.strotmann.de/wiki/Wiki.jsp?page=Extended%20Atari%20FIG-Forth%20APX20029
     
    You can see the results of this:
  2. tschak909
    Hello everyone, progresssing on fig-FORTH.
     
    As part of my work, I am hammering away on tools that I will need to write the game. One of the tools I absolutely want, is a full screen text editor, it will have very simple requirements:

    split a 64 character fig-FORTH screen line into two 32 character windows, which when the cursor moves, will be scrolled over.
    provide a way to switch between the following modes, selectable by the yellow keys:
    Edit mode - Edit a given screen (OPTION)
    Select Mode - Select a given screen (SELECT)
    FORTH Mode - quickly type FORTH words to test things. (START)

    The screen will be divided into a few areas, from top to bottom:
    The Current Screen #
    The Editing Window showing the current screen.
    A Status Line (need to add this into my display list) showing EDIT MODE, SELECT MODE, or FORTH MODE.
    A four line window for entering FORTH commands or showing edit HELP.

    I have implemented initial versions of the needed words to setup the screen memory, to convert between ATASCII and ANTIC screen codes, various display primitives for writing to parts of the screen outside the E: device's reach (SEMIT, STYPE, SSPACE, SSPACES, SD.R, S.R, S., etc.). All of these words are written in FORTH, and I haven't sped anything up, so it does need some love there.
     
    Now, I need to start writing the primitives to move around the displayed screen. I am posting a video here, enjoy
     
    -Thom
     

  3. tschak909
    Hello everyone,
     
    I've been putting little bits of musings on FORTH, as I use the fig-FORTH implementation on the Atari 800 to write a graphics demo that I am working on.
     
    Because FORTH isn't a language, it's an environment with a way of life radically different than anything else out there, It has seriously caused me to reexamine my perspective on solving problems through computer programming.
     
    I've spent the better part of 25 years writing computer programs. At first, it was me, as a kid, looking around this crazy world of the computer (at this time, an Atari 800), trying to see what I could get away with. I progressed to other languages, other processors, other systems, eventually entering into the workplace as a professional programmer, not forged from the halls of academia, but from my own autodidactic experience.
     
    Along the way, I explicitly exposed myself to a variety of environments, both in play and in work, because I am genuinely curious, creating things interests me, and tools interest me because tools allow me to create, they allow me to visualize what is going on in my mind, and to do what I love to do best, to solve the problem. I use a healthy set of these environments that I've learned, on a daily basis, ranging from system languages like C, C++, Objective-C for application development, to PERL, PHP, Ruby, Python for web or small user facing applications, to even specialized languages like Erlang, which is unparalleled for distributed application development.
     
    And yet, I am very disconcerted with the state of application development today. We create large, overly generalized programs, on top of layer cakes of generalized programming and operating system infrastructures which serve ultimately, to service themselves, with the side effect being that you, the user, are able to use the system, for....whatever you may generally want to use it for, so long as we have an App to do that. This hypergeneralizaton exists, because we are taught to create general solutions to problems; try to solve as many derivations of a problem that you can think of...
     
    ...but we never think of everything, do we? Somebody else will always want another feature.
     
    So over time, these features aggregate into software, and, instead of writing software to solve the problem directly in front of us, we combine software off the shelf from different sources. A programming toolkit here, a physics library there, and we feel that these things get us to the finish line, faster. Sometimes, they do, but at a price. As Chuck Moore once said, "Programmers do not write megabytes of code. They borrow kilobytes of code; do this a thousand times, and you have a megabyte of code."
     
    But the problems do not end there, in fact, they often start there. Bugs are everywhere, and it is a simple fact that none of the code a programmer will be using is bug free. This does not count the program code that a programmer writes himself. So therefore, a programmer ultimately pays for mistakes he isn't accountable for. This is a fact of software development that we take in stride, but often fail to factor into many design decisions when we make our assumptions on what tools to use to solve the problem. It's not just you developing your software, it's the rest of your team, the team that created your software toolkit, the team who created your programming language, ad nauseam; your programming team is now indirectly hundreds to thousands of people, most of which you can not contact or collaborate with, the advances in collaborative software development notwithstanding, the simple fact is, we do not live in a world where we can fix everything we ourselves did not make.
     
    It is in this climate of making large balkanizing pieces of software, that I find myself introspectively thinking, what can be learned, and from where?
     
    And in this context, what am I learning from FORTH?
     
    I will stop here for a moment, and stress, that I do not see FORTH as a panacea for all of the problems of programming. However, it does espouse a great deal of good ideas which should be evaluated when you are looking for ways to solve the problem at hand.
     
    FORTH is teaching me to solve the specific problem at hand. In FORTH, you do not write programs, you create vocabularies. It is in this context that I find FORTH's approach truly brilliant. Every problem must be able to be understood. We as human beings talk about problems, we have words to find if the problem exists, to describe the problem, to find approaches to solve the problem, even to find if our approach is the right one for solving the problem.
     
    Even the largest of problems may have 500 to 1000 words at most, and this approach applies to everything. You may have words to manipulate an image, DESATURATE, COLOURISE, RETOUCH, at the same time, in an automotive factory, you may have words like ATTACH, ASSEMBLE, or CHECK. We take these words, and assemble solutions to a given problem at hand, and regardless of what anyone may tell you, all problems are specific. We often spend too much time, trying to solve specific problems using tools that are far too general for the task, and thus we find ourselves trying to deconstruct the problem and reassemble it in a generalized context, often losing subtlety or nuance that may be required to solve the problem in the first place.
     
    FORTH is not a language, but an environment for making vocabularies specific to a given problem. These vocabularies are then assembled into useful tools for an intended user. Thus by this very definition, a concept of a "standard library" that you would often see in other languages like C is both moot, and superfluous; when it becomes easier to make your own tools to solve the problem at hand that completely fit what you're doing, why would you bother with using a set of standard functions?
     
    FORTH has also shown, that as an environment, it has everything needed to utilize the hardware at your disposal, to solve the problem at hand. There are words for reading and writing to memory, to disk, to graphics hardware, to audio hardware, and more. Because FORTH provides this complete environment, and you are able to create precisely what you need quickly, you do not need this intermediate layer of an operating system to try and make sure things can talk to each other. The individual pieces that talk to peripherals are simple, and map to simple concepts within the language, so the usage of said tools are simple.
     
    The price of all this, is that you, the programmer, live in this place that you've created, alone. But when you can create exactly what you need, exactly when you need it, quickly, is this a bad thing?
     
    I am still thinking it through.
     
    -Thom
  4. tschak909
    Once I was able to type in the editor, I was able to start re-entering screens from scratch for the FIG-FORTH.
     
    To do this, I am referencing three different sources:
     
    * Carsten's Atariwiki containing the SCREENs for Enhanced Fig-Forth 1.1
    * William Ragsdale's FIG-FORTH Installation Guide, detailing the bootstrapping of the original 6502 FORTH, which also contains info for the editor.
    * the APX-20029 Extended Fig-Forth disk, as some screens weren't in Carsten's dump, but are required for basic operation (the Error messages, etc.)
     
    I have made a quick vid showing me entering the code for SCREEN 31 (part of the editor).
     
    http://youtu.be/IXU4B-9rP8s
     
    enjoy,
     
    -Thom
  5. tschak909
    I am roughly halfway through with reconstructing the screens on the APX Extended Fig-Forth disk. There is enough here to be able to use the Debugging Aids (DUMP, CDUMP, etc.), the EDITOR words for manipulating FORTH screens, and the 6502 FORTH ASSEMBLER.
     
    If you want all three of these tools, an 18 LOAD is sufficient (provided of course you are in DECIMAL mode)
     
    Onward...
     
    -Thom
     
    You can see it working here:
     

  6. tschak909
    Hello everyone. I am creating a series of tutorial and exploratory videos chronicling my journey through learning FORTH and applying it to the Walking Life demo that I am working on in FIG-FORTH.
     
    You may subscribe to my channel on youtube: http://www.youtube.com/tschak909/ to see them, and to start off, and I will be posting them here, as I complete them:
     
    Introduction: http://www.youtube.com/watch?v=JaNn1cnvBAI
    Screens in FIG-FORTH: http://www.youtube.com/watch?v=nZKYONc7sYs
    Editing Screens in FIG-FORTH: http://www.youtube.com/watch?v=-E5zQZApJRQ
    Making More Useful Screens in FIG-FORTH:
     
    Enjoy! More to come. I am trying to show that FORTH is a very powerful language that is approachable, and I hope these videos go a step towards showing that it is a good fit for a language for a small system like the Atari 8-bit platform.
     
    -Thom
  7. tschak909
    Afternoon,
     
    I've made a series of 4 YouTube videos describing in detail the conceptual work, and the creation of words to implement an ANTIC disassembler tool in FORTH to compliment the ANTIC assembler that I wrote.
     
    This basically demonstrates how FORTH can quickly be used to make useful tools that can be intermingled with the development of programs in FORTH so that you don't have to load entire other programs to get stuff done, but rather just flow from one vocabulary of words to the next.
     




     
    Let me know what you guys, think.
    -Thom
  8. tschak909
    And now after some initial work, the graphics display for the shields is started... yes.. I will be doing a better job on the graphics soon, I just wanted something in place to mess with. :-P
     
    (can some people help me out on the graphics later?) :-)
     
    I did realise that I will need to kill the shield graphics, the moment the invaders touch it, because of the vertical scrolling technique i am using.. the LMS to the screen memory that holds the shields gets _CLOBBERED_ ... oops, didn't think about that one hahaha.
     
    more to come, later.
    -Thom
     
    <-- the shields, finally on screen.
  9. tschak909
    muahahahahaha, THEY LIVE!
     
    After combining the horizontal and vertical scrolling techniques from the other code tests, I've been able to make smooth scrolling produce a nice silky smooth march both horizontally, and vertically.. the march ends once the invaders have marched all the way to the bottom of the screen.....
     
    Next up! Player motion!
     
    -Thom
     

  10. tschak909
    I have temporarily tabled the breakout invaders project, so that I could pursue doing a game on the Atari 2600. After about four days worth of work so far, I've managed to make a stable kernel, and am working on the game every day.
     
    So far, the game uses a 25 line playfield, rendered at 8 pixels tall, and I am working on the needed coarse scrolling before I modify it for fine scrolling.
     
    I am definitely enjoying this, and it's definitely a zen-like experience for me.
     
    Once the game reaches a playable state, I will post to the Homebrews forum.
     
    pescoman_v9.zip <-- current stable kernel.
  11. tschak909
    I am resuming work on Salmon Run, I had to calculate 255 possible random combinations for playfield state, I did it all inside a text file, separated into columns in which I first drew the binary patterns, and then calculated the PF1, PF2, PF3, and PF4 data accordingly....
     
    A snippet of the graphic notepad file:
     

    RIVER1 RIVER2 RIVER3 RIVER4 PF1 PF2 PF2 PF1 Normal Reversed Normal Reversed --------------------------------------------- 00 11000000 00000000 00000000 00000011 192 0 0 192 01 11110000 00000000 00000000 00001111 240 0 0 240 02 11111100 00000000 00000000 00111111 252 0 0 252 03 11111111 00000000 00000000 11111111 255 0 0 255 04 11111111 11000000 00000011 11111111 255 3 3 255 05 11111111 11110000 00001111 11111111 255 15 15 255 06 11111111 11111100 00111111 11111111 255 63 63 255 07 11000000 00000000 00000011 11111111 192 0 3 255 08 11110000 00000000 00001111 11111111 240 0 15 255
     
    I have attached the code here:
     
    pesco_pacman_v8a.zip
     
    I also developed a quick tool to output the necessary .byte statements using Ruby:
     

    # salmon run graphic dump dev tool # t.cherryhomes 2007-04-05 pf1data = Array.new pf2data = Array.new pf3data = Array.new pf4data = Array.new pf1binary = Array.new pf2binary = Array.new pf3binary = Array.new pf4binary = Array.new l = 0 File.open("riverdata.txt") do |f| while line = f.gets if (l < 4) then # do nothing. else currentLine = line.split(/\t/); currentBinary = currentLine[1].split pf1data.push(currentLine[2]); pf2data.push(currentLine[3]); pf3data.push(currentLine[4]); pf4data.push(currentLine[5]); pf1binary.push(currentBinary[0]); pf2binary.push(currentBinary[1]); pf3binary.push(currentBinary[2]); pf4binary.push(currentBinary[3]); end l+=1; end end File.open("riverdata.asm","w") do |f| f.puts "PF1Data" pf1data.each do |i| f.puts "\t.byte " << i end f.puts "PF2Data" pf2data.each do |i| f.puts "\t.byte " << i end f.puts "PF3Data" pf3data.each do |i| f.puts "\t.byte " << i end f.puts "PF4Data" pf3data.each do |i| f.puts "\t.byte " << i end end puts "Done.\n"
     
    and it works just fine. :-)
     
    Now, I am going to hammer out the asym kernel, will keep you guys posted :-)
  12. tschak909
    An Observation to anyone who has ever wanted to pursue a creative discipline, but didn't do so because they felt they "didn't have sufficient inspiration:"
     

     
    I've been writing software for the better part of 25-30 years. I have never written games during this period of time, because I didn't think I had a game idea sufficiently interesting enough to write. I have also followed homebrew gaming development since the late 1990s, when I first joined the Stella mailing list (for Atari VCS homebrew coding enthusiasts)...
     

     
    ...and in that time, some 20 some odd years, I had wanted to write a game...
     

     
    ...and finally, on May 31, 2016, that game idea came to me, fully formed, in my head, in a massive flash.
     

     
    But, as I started work on this idea, I realized something: If I had been writing little practice games, all these years, I would have been infinitely better prepared to solve the problems that I am working through now, such as understanding the tricks needed to write a proper display kernel for the Atari VCS.
     

     
    I am now compressing some 20 years of learning, into a much shorter amount of time, which is both necessary, and very painful.
     

     
    So, I beg all of you, if you want to make anything, anything at all, make it, and keep making it, over and over again...you will get better, and when that amazing idea comes around, you will be mentally equipped to be able to actualize it.

  14. tschak909
    After beating my brains out on what eventually turned out to be a relatively simple solution, I have been able to implement smooth scrolling in the game (as well as work on the lives display for player 1 and 2) .. it turns out i need to do some slight recalcultion of the river display because I am _WAY_ over my visible line calculations.. No matter, just a few adjustments which i will take care of tonight....
     
    I also still need to fix the scrolling algorithm slightly (move the window boundary constraints directly into the kernel so that the wrap around happens immediately after the last line in the visible buffer is drawn.
     
    after which, I will work on the joystick routines (and their related velocity routines for the smooth scroll.),
     
    In the mean time, I leave you with my daily zip and screenie:
     
    pescoman_v91.zip <-- yay, score and lives!
     
    pescoman_v96.zip <-- current source and bin
     
    -Thom
  15. tschak909

    Screen Tests!

    By tschak909,

    I am slowly progressing. I have the first DLI routine set in place to set the colors. Had to use a chain of routines each modifying the DLI vector at the end of each pass. Because I had to make four distinct color changes, I decided to hard-code them into the routine, so that I could minimise the number of cycles being done. I will be modifying the look of the screen layout from here, but now I have something i can work with and mould to look the way I want it to look.
     
    You may have noticed I used a narrow playfield. I did this to be more in line with the aspect ratio of the original game, as well as to give me more cycles per line to do color palette changes. I am glad the idea I had worked. I just need to tweak the colors, maybe make them brighter, and perhaps play with the top score line a bit. I wanted to keep it nice and readable, but if I want color, I'll probably have to use an antic mode 4 line there too, I just wish I could have a border around the whole thing..but I guess that's out of the question....
     
    I have hardcoded and filled the screen with invaders right now, just so i can get a sense of the space of the screen, there will not be this many invaders on screen at once, I know they need space to breathe and move around....
     
    The only real bug I had, was that I had one too few DLI instructions defined in the display list, so the interrupt vectors were being cycled through, one less than should be, giving an interesting stair-step effect, whoops
     
    Now i will design the character for the player....
     
    Screenshots posted below:
     
    <-- Before any DLI treatment, totally monochrome
     
    <-- After the DLI treatment, technicolor!
     
    -Thom
     
    I have also included a dos 2 image with the current source.
     
    Disk Image:
  16. tschak909
    After much deliberation, I finally managed to get the memory clear/fill function debugged.
     

    ; ; FILL PAGES MACRO ; ; %1 = beginning page to fill ; %2 = number of pages to fill (should be - 1) ; %3 = byte to fill with (e.g. $00) ; ; $CC = 00 for top of page boundary ; $CD = page currently being filled ; $D5 = corresponding to ending page ; .MACRO CLRP STCL LDA %1 STA $CD LDA #00 STA $CC LDY #0 LDA $CD ADC #%2 STA $D5 CRLP LDA %3 DEY STA ($CC),Y BNE CRLP INC $CD LDA $CD CMP $D5 BEQ CRLP BCC CRLP .ENDM
     
    So, what do you guys think? How can I make this so that it can fill regions of memory that don't end on nice page boundaries? Should I need to do that?
     
    -Thom
  17. tschak909

    Shields, take 2

    By tschak909,

    Hello guys,
     
    Have been refining the shields a bit, and have created a string of DLI interrupts that do RANDOM color changes to COLPF2 on a per scanline basis, creating an electrified pulse effect.. I will refine this, later...but the DLI code is in place. I just need to do a two pronged subroutine that clears the LMS and mode E and DLI bits, and do a slight change to re-vector over the additional DLI routines when not in use. Basic missile shooting is sort of in place, I need to make it track the ship, no collision detection yet..but soon.
     
    Pictures and current code attached.
     
    -Thom
     
    <-- the electrified shields.. a still shot, the bars randomly change.
     
    <-- current code.
  18. tschak909
    Decided for my first game to be a Space Invaders type game. Did some initial sketching in Envision, and am now posting the results of my work.
     
    The graphics are meant for antic mode 4 displays, with each line setting a DLI to change the color palette of each line essentially doing a hue change.. I chose to use all four colors for a shaded look rather than a non-shaded flat but colourful look.
     
    What do you guys think?
     
    <-- editing the characters
     
    <-- doing a basic tile test.
     
    -Thom
  19. tschak909
    I am currently working on the player's missile routine, and as soon as it is debugged, i will be applying it to the enemies as well.. I will investigate using player and missile sprite multiplexing to get more than say, two enemies firing at the same time. But until I actually get to that point, I am learning things by trial and error, and looking at others code.
     
    -Thom
  20. tschak909
    Starfield Update:
     
    Definitely better this time, I've tightened the kernel routines a little, and made sure the starfield happens inside horizontal playfield borders. But I need to be able to fix the streaks happening during display... If I enable the WSYNC in the kernel code, the stars stabilise and the streaks stop, HOWEVER, there is a big black hole on the lower left corner of the screen.. WHAT GIVES? WTF? ... ok well, I am tabling this for now, and continuing on.
     

     
     
     
    continuing onto the gameplay logic.
     
    -Thom
  21. tschak909
    I've done the first little test of some vertical scrolling techniques using a moving ANTIC JMP instruction, so far it works, i just need to alter the counter on the up cycle slightly, but one question.. how do I make the scrolling completely smooth, with no jumps?
     
    -Thom
     
    Source Code:
     
    ;
    ; TEST PROGRAM TO TRY MY DISPLAY LIST THEORY.
    ;
     
    ; NOTES
    ;
    ; 5 INVADERS LINES OF 8 PIXELS HIGH
    ; 2 BLANK LINES BETWEEN EACH SEGMENT
    ;
    ; USING ANTIC MODE 2 TO SEE THE LINE DIVISIONS
    ;
     
    .INCLUDE atariequ.asm
     
    UPCTRL = $80 ; UP LINE COUNTER
    UPCTRH = $81 ;
    DNCTRL = $82 ; DOWN LINE COUNTER
    DNCTRH = $83 ;
    UPDOWN = $84 ; GOING UP OR DOWN?
     
    *=$2000
    JMP START
     
    ;
    ; DISPLAY LIST
    ;
     
    DLIST .BYTE $70 ; 3 BLANK 8-LINES
    .BYTE $70 ; FOR THE
    .BYTE $70 ; BORDER
    UPJMP .BYTE $01,<UPBOT,>UPBOT
    UPBLNK .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    UPBOT .BYTE $00 ; 1 BLANK LINE
    .BYTE $55,$00,$49 ; BONUS DISPLAY
    .BYTE $40 ; 5 BLANK LINES
    .BYTE $52,$00,$50 ;
    .BYTE $20 ; 3 BLANK LINES
    .BYTE $52,$00,$51 ;
    .BYTE $20 ;
    .BYTE $52,$00,$52 ;
    .BYTE $20 ;
    .BYTE $52,$00,$53 ;
    .BYTE $20 ;
    .BYTE $52,$00,$54 ;
    DNJMP .BYTE $01,<DNTOP,>DNTOP ; JUMP INSTRUCTION FOR MIDDLE OF SCREEN
    DNTOP .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    .BYTE $00 ; 1 BLANK LINE
    DNBOT .BYTE $00 ; 1 BLANK LINE
    .BYTE $41,<DLIST,>DLIST ; JUMP BACK TO BEGINNING OF DLIST AT VBLANK
     
    ;
    ; MAIN PROGRAM
    ;
    START CLD
    SCTR LDA #<UPBOT ; SET INITIAL COUNTERS
    STA UPCTRL ;
    LDA #>UPBOT ;
    STA UPCTRH ;
    LDA #<DNTOP ;
    STA DNCTRL ;
    LDA #>DNTOP ;
    STA DNCTRH ;
    LDA #$01 ;
    STA UPDOWN ;
    SDMA LDA #$3D ;
    STA SDMCTL ; SET UP PLAYFIELD
    SDLS LDA #<DLIST ; SET UP DISPLAY LIST
    STA SDLSTL ;
    LDA #>DLIST ;
    STA SDLSTL+1 ;
    SVBI LDA #$06 ; IMMEDIATE VBI
    LDY #$00 ;
    LDX #$06 ;
    JSR SETVBV ;
    LOOP JMP LOOP
     
     
    ;
    ; VBI ROUTINE
    ;
    *=$0600
    VBI TXA ; PUSH EVERYTHING ONTO STACK
    PHA ;
    TYA ;
    PHA ;
    LDA #67
    STA COLOR2
    LDA RTCLOK+2 ; GRAB REALTIME CLOCK VAL
    AND #$0 ; EIGHT VBI
    BNE VBDON ; SKIP IF THIS ISN'T OUR TIME.
    LDA #$00 ; ARE WE GOING UP OR DOWN?
    CMP UPDOWN ;
    BEQ GOUP ;
    GODOWN LDA #39
    STA 712
    DEC UPCTRL ; UPDATE COUNTERS FOR THE MOVE.
    INC DNCTRL ;
    LDA UPCTRL ;
    CLC ;
    ADC <UPJMP ; ADD THE LO BYTE OFFSET OF THE JMP INSTRUCTION
    STA UPJMP+1 ; UPDATE THE DLIST
    LDA DNCTRL ;
    CLC ;
    ADC <DNJMP ; AND AGAIN....
    STA DNJMP+1 ; UPDATE THE DLIST
    LDA #$00 ; 124 LINES PASSED?
    CMP DNCTRL
    BEQ SETUP ; FLIP THE FLAG TO UP
    JMP VBDON
    GOUP LDA #23
    STA 712
    INC UPCTRL ;
    DEC DNCTRL ;
    LDA UPCTRL ;
    CLC ;
    ADC <UPJMP ;
    STA UPJMP+1 ;
    LDA DNCTRL ;
    CLC ;
    ADC <DNJMP ;
    STA DNJMP+1 ;
    LDA #$00 ;
    CMP UPCTRL ;
    BEQ SETDN ;
    JMP VBDON
    SETUP LDA #$00 ; SET FLAG TO UP
    STA UPDOWN ;
    JMP VBDON ;
    SETDN LDA #$01 ; SET FLAG TO DOWN
    STA UPDOWN ;
    JMP VBDON ;
    VBDON PLA ; TAKE EVERYTHING OFF OF STACK
    TAY ;
    PLA ;
    TAX ;
    JMP SYSVBV ; AND JUMP TO THE DEFERRED VBI VECTOR
    ;
    ; SCREEN MEMORY
    ;
     
    *=$4900
    .SBYTE " () "; BONUS DISPLAY
    .SBYTE " "
    .SBYTE " "
    .SBYTE " "
    .SBYTE " "
    .SBYTE " "
    .SBYTE " "
    .SBYTE " "
     
    *=$5000
    .SBYTE " !! !! !! !! !! !! !! !! "; INVADERS LINE 1
    .SBYTE " "
    .SBYTE " "
    .SBYTE " "
    .SBYTE " "
    .SBYTE " "
    .SBYTE " "
    .SBYTE " "
     
    *=$5100
    .SBYTE " @@ @@ @@ @@ @@ @@ @@ @@ "; INVADERS LINE 2
    .SBYTE " "
    .SBYTE " "
    .SBYTE " "
    .SBYTE " "
    .SBYTE " "
    .SBYTE " "
    .SBYTE " "
     
    *=$5200
    .SBYTE " ## ## ## ## ## ## ## ## "; INVADERS LINE 3
    .SBYTE " "
    .SBYTE " "
    .SBYTE " "
    .SBYTE " "
    .SBYTE " "
    .SBYTE " "
    .SBYTE " "
     
    *=$5300
    .SBYTE " $$ $$ $$ $$ $$ $$ $$ $$ "; INVADERS LINE 4
    .SBYTE " "
    .SBYTE " "
    .SBYTE " "
    .SBYTE " "
    .SBYTE " "
    .SBYTE " "
    .SBYTE " "
     
    *=$5400
    .SBYTE " %% %% %% %% %% %% %% %% "; INVADERS LINE 5
    .SBYTE " "
    .SBYTE " "
    .SBYTE " "
    .SBYTE " "
    .SBYTE " &nb
  22. tschak909
    Wanted to let you guys know, that I am still working on the game. I've been in the process of re-building it in ATASM on the Linux side, instead of using MAC/65 inside the Atari 800 itself. I got tired of being squinched into 40 columns.
     
    My current goal right now, is to refactor and get the invaders display working again, then work on getting the bottom half of the display working, and get player movement working.
     
    I have put together a more comprehensive set of system equates, merging information from the Programmers Card on De Re Atari, and the ATARI OS SYSTEM EQUATES file, from an internal Atari document dated March of 1982. I am modifying the memory map chart that I provided earlier, to more accurately reflect what's being used in the zero page, but it is nice to know that the top 128 bytes of page 0 are available "for user programs"
     
    I have attached a picture of a crater design that I am working on for the bottom half of the background.
     
    Talk to you guys soon,
    -Thom
     
    <-- doing a sketch of the moon background.
  23. tschak909

    Screen Tests II!

    By tschak909,

    Greetings all,
     
    Am nearing the final revision of the playfield layout that I want. I thought I would paste a screenshot so that everyone here could see what I am working on. I have posted two shots, one with NTSC emulation, and one without, it's giving me a reference as to what I need to correct, graphics-wise.
     
    (yes, I am aware of the hanging pixel on the bottom invaders, I am using it as a special reference right now for a bounding box).
     
    <-- with NTSC emulation
     
    <-- without NTSC emulation
     
    <-- source code to screen test.
     
    Some further notes:
     
    I will be using players/missiles from this point on, to provide all the non-scrolling elements (this includes all the background elements, player missiles, the breakout ball, and any additional player missile states not covered here.. I will be needing to do some serious creative thinking to get all this working together....
     
    but knowing that:
     
    I need a gun for the player
    I need a gun for the enemies (maybe a limit of two shooting at once.)
    I need a player for the breakout ball when it enters breakout mode
     
    at the very least,
     
    what do i have left over to draw background elements? (thinking)
  24. tschak909
    Ok, well, got my memory clearing routine to work properly, was just a few little typos. Basically was very easy. I had decided to make two separate macros that were self contained for clearing single and multiple pages becase the addition of clearing multiple pages was just a few instructions more, and didn't make sense to loop back through re-setting everything for each individual page....
     
    I have made a couple small test programs just going through loops and setting values, just trying to get a handle on some very basic things.
     
    color1 - flip through all 256 colours and loop
    color2 - flip through colors 40 through 50, looping up, then down, each increment followed by a WSYNC
     
    I will be posting my little snippets in MAC/65 format and compiled format inside ATR disk images (Atari DOS format.)
     
    Well, I'm re-learning.. bit by bit... albeit slowly for now.
     
    _pesco_pacman_v7.zip
  25. tschak909
    Evening all,
     
    Just hacking away on the game. I have decided to add a set of three shields at the bottom of the playfield utilising ANTIC mode E for the graphics. I drew some preliminary shields using GIMP, and systematically converting each group of four pixels into their appropriate nibbles for the screen bytes. Is there an easier way to do this? hmm, i'll just plod along for now.
     
    On the missile front, the missiles are firing properly, but I need to speed them up slightly, it is smoothly shooting however. Lessons learned? be sure to not overdo EORs.
     
    -Thom
     
    <-- drawing the shields, guide lines show byte boundaries.
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2023 AtariAge

×
×
  • Create New...