Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


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.

    now I can just type HELLOWORLD and have it output:

    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
    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.
  3. 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.
    <-- the shields, finally on screen.
  4. 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!

  5. 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!
    I have also included a dos 2 image with the current source.
    Disk Image:
  6. tschak909
    Still reading...and I've come across something in De Re Atari that has me a bit curious. I have cross posted this to the forum, but, I am posting it here too for my journal....
    In the book De Re Atari, Chris Crawford talks about moving the player vertically through memory. It's very straightforward...
    of special note, is that next to last sentence in the paragraph.
    If high speed is necessary, the loop can be trimmed to move only the image bytes themselves rather than the whole player; then the loop would easily run in about 100-200 microseconds.
    What is he talking about there?
  7. 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?
  8. tschak909
    It's so strange to be coming back to this platform, after not seeing it since 1989. I completely missed the eastern european renaissance that occurred in the early to mid 1990s (which is still happening even today.), and am amazed to see just what has been created for the ANTIC based Atari systems since I left.
    It seems I am not the only person who has decided to come back, After combing the posts here on this site, there are a lot of developers pumping out things here too! Wow, a Rally-X game, a Super Mario Bros platform game, and a few other things, very impressive. The development tools have also improved too! EnvisionPC is fantastic! And the breadth of host-side 6502 cross assemblers made my head spin. (I decided on using MAC/65 )
    I started early this morning, basically re-learning everything from scratch. Damn! I forgot it all ) I found copies of some very good Atari 800 programming materials on AtariArchives.org and started reading and typing things in, just to get the hang of it again.
    I am currently trying to make some basic macros right now, namely, I finished the first version of my system equates file, and I started working on my own set of core macros which i will want to use throughout my code.
    Currently trying to debug my memory clearing routines.. darn, it's spiraling out of control. Will try to re-write it again to use a different approach.
    I seem to be making basic mistakes as to the operations of the compare instructions. Will look at some existing code to get a better approach.
  9. 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.

  10. tschak909
    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.
  11. 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

  12. 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.
  13. 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.
  14. 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)
    You can see it working here:

  15. 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).
  16. 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:
    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 :-)
  17. 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
  18. 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.
    <-- the electrified shields.. a still shot, the bars randomly change.
    <-- current code.
  19. 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.
    <-- drawing the shields, guide lines show byte boundaries.
  20. 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.
  21. 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.
  22. tschak909
    Evening fellas,
    I took my first crack at a starfield tonight, it still needs a _CRAPLOAD_ of work, the stars flicker, but I do know my technique will work with the proper timing. I will try to tie VCOUNT in and see if I can carefully time the stars to appear on the correct scan lines without flicker, I'm going to try to keep stars down to one per line..maybe I can make something look good... if worse comes to worse, I will try to use two missiles for this, but I don't want to waste precious sprite space at this point.
  23. tschak909
    I have completed the first bits of code to handle player motion, I will leave as is for now, and continue on implementing the rest of the core implements for game play, then return to the various motion routines to add the velocity tables.
    I have also put a placeholder in the bonus section up top for now, and redid the font slightly to make it more readable.
    p.s. I am losing a little bit of granularity doing ANDs on RTCLOK, what if I wanted to do vblank checks on anything but 1 2 4 and 8? what would be the best way to do that?
  24. tschak909
    Well guys, after a lot of debugging, I have the horizontal scrolling motion working properly.. I have sped it up so that it could be seen.
    I have attached the code below, but basically my approach is this:
    * use the main line code to set global states, go left? go right?
    * use the VBI to update actions that need to happen per frame, update the zero page locations for current HSCROL and LMS positions.
    * use the DLI to update the HSCROL registers appropriately.
    it's coming along, bit by bit... now it's time to put in the first bits of player code
    (and no, this is NOT a final on the motion... I will be tweaking the motions using a lot of hand tables to give the illusion of speeding up and slowing down...)
    what do you guys think?
  • Create New...