Jump to content

Gibstov

Members
  • Content Count

    237
  • Joined

  • Last visited

Community Reputation

308 Excellent

1 Follower

About Gibstov

  • Rank
    Chopper Commander

Recent Profile Visitors

3,176 profile views
  1. Awesome. Thanks man, I really appreciate it. It makes me happy that your daughter adores the game, and that it brings a younger generation to the old Atari computer. 😊
  2. In the flash game, you can unlock all the characters on the "Pony Select" screen by typing in the word: CELESTIA In the Atari version you can unlock the characters on the "Pony Select" screen by holding down the HELP key and pressing up on the joystick.
  3. I found the original Adventure Ponies flash game on archive.org if any one is interested. https://archive.org/details/adobeflash-adventureponies Since Adobe Flash is legacy now, I found a way to run it as well, using the Adobe Flash Player 32 (specifically the "Download the Flash Player projector content debugger"). https://www.adobe.com/support/flashplayer/debug_downloads.html
  4. I used Antic Mode 4, narrow playfield 32x24 chars is Adventure Ponies;. So there is one, but I am sure many others
  5. An example of using :NAME and a quick note about #ID The command :NAME allows you to assign a memory address to an #ID. Also, though it is not documented, the #ID FF is reserved. #ID FF is assigned the value of $E000 (the address of the built in character set). In this example, :NAME is used to view the international char set ($CC00) and then using #ID FF to switch back to the default char set. ; Use :NAME to display international charset ; #ID FF is reserved and used to refer to default charset E000 :head :name #id f1 %sz CC00 ;%sz is memory address to assign to #ID :code #id c1 #ws 1 #CH FF ;set CHBASE to databank FF (E000) :page #ch f1 ;set CHBASE to databank f1 (CC00) international charset :text Example of using the international charset Spell words like jalape[ctrl-b]o or attach[ctrl-u] Or an 80's Hairband M[ctrl-o]tley Cre[ctrl-j] :fill #mb 70 ;insert some blank lines :call #id c1 ;switch back to default charset :text | Set attribute #CH to FF to switch | | back to the default charset | :fill
  6. Sorry just so we are on the same page here as regards to relative links. As far as N: device or any device is concerned, it would be given the full address/filespec. So in the example where someone clicked on a link, for example "Example2.DOC", as far as FujiNet is concerned, Neon would send it "N:tnfs://my-test-server/NeonTest/Example2.DOC.". So relative links are handled by Neon, by keeping its own path and the inserting it where needed. So I am thinking that it should work, or am I still missing something?
  7. Can I ask you some question about FujiNet, I have been working off of assumptions when developing this, but may have some misunderstanding on how it works. So please indulge me with this theoretical scenario. Suppose you were to set up a tnfs server say: tnfs://my-test-server/ And then create a folder called NeonTest. Suppose the example above, under "relative links", was saved as a file called Index.DOC. And then there were 3 other files, Example1.DOC, Example2.DOC, and Example3.DOC also in that folder. Also, let's assume we have booted an Atari, and loaded the N: device driver/device handler, and have Neon loaded. First question: In theory we should be able to load up the Index.DOC in Neon, by choosing R to read, and then entering in: >N:tnfs://my-test-server/NeonTest/Index.DOC to pull the file down over the FujiNet. Is this accurate or will this not work. Second question: If the above works, then theoretically the relative links should work. When you click on example one, it would resolve to N:tnfs://my-test-server/NeonTest/Example1.DOC and example two would be N:tnfs://my-test-server/NeonTest/Example2.DOC In theory this should work right, I am pretty sure the relative stuff works, but more importantly, it should be able to pull each document down, if it has the full address? "Since ADF is a specification as well as software, there's excellent potential for it to run on non-A8 platforms. This opens the door to things like an ADF daemon handling page compilation on a *nix box acting as the server, much as tnfsd runs on remote non-Atari hosts." It should be fairly straight forward to port the Neon Compiler (Make) to other platforms (famous last words), because the program is written in C. "BTW: any plans for implementing something analogous to the HTTP PUT and GET methods? With those, the possibilities of building things like a BBS or platform-specific forum would be very close." Maybe in the future, I was thinking that Form elements could be added. Kind of using the same frame work, maybe moving the joystick will move the focus to the various controls. Click the button on the control to change its value. Though I imagine the way this would work is it would save the Form values as a file.
  8. Relative vs absolute file specifications. Absolute filespec: D:example1.doc or D1:example1.doc Relative filespec: example1.doc All ADF commands use the absolute filespec except the :LINK command*. The :LINK command can use either the full absolute file spec or can use the relative filespec. This makes development easier. You can develop on a PC using Altirra with its built in virtual hard drive feature using the H: device. Then you can easily copy the DOC files over to a floppy disk and all the links will work without having to manually change H: to D:, and recompiling. ; Absolute Links :head :page :text Example 1 :link $fs "D:Example1.doc" :text Example 2 :link $fs "D:Example2.doc" :text Example 3 :link $fs "D:Example3.Doc" $li "About" ;link to a page in Example 3 :fill Same document using relative links instead of absolute links. ; Relative Links :head :page :text Example 1 :link $fs "Example1.doc" :text Example 2 :link $fs "Example2.doc" :text Example 3 :link $fs "Example3.doc" $li "About" ;link to a page in Example 3 :fill * All commands with the exception of :LOAD, load files at compile time and the data becomes part of the document, so relative links are not as important.
  9. Awesome. I really want to start testing on FujiNet, the original inspiration for this application.
  10. As noted in an earlier post, if you need need to display an image over 4KB, it must be split into two. The magic number to split the file at, assuming you are going to display it a mode such E, is FF0 (4080). This is the last full 40 byte line before 1000 (4096). This example shows how to display an image over 4KB. I found the source for the image here: http://gury.atari8.info/detail.php?id=14559&src=8 ; Example of displaying an image greater than 4KB by splitting it into two :DATA statement :head :data #id a1 $fs "H1:clown1.pic" %sz ff0 ;Split the file at FF0(4080), last full line before 1000(4096) :data #id a2 $fs "H1:clown2.pic" %sz e14 %of 10 ;we need to offset by 10(16) to start at 4KB :page #c4 94 #c5 38 #c6 0F ;We need two view statements to view the full picture :view #id a1 #mo e #ln 66 ;66(102) lines because 4080/40 :view #id a2 #mo e #ln 5A ;5A(90) lines = 3604/40 :fill
  11. I updated the ADF Command List document to be more comprehensive. You can find it here, or in the original post. Atari Document Format.txt
  12. A note on memory management. On the Atari, there are a few pitfalls regarding crossing certain memory boundaries. Also char sets and Player Missile graphics must be aligned on 1KB memory boundaries (2KB boundary for single line PM Graphics). Crossing a 4KB memory boundary. On the Atari, if screen memory crosses a 4KB boundary, it will cause the output to become corrupted. In Neon, if you are using either the :TEXT or the :BYTE command, you don't need to worry about this. The compiler will automatically take care of crossing any 4KB boundary. However, if you are using the :DATA command to create images, you will need to make sure that the :DATA doesn't cross a 4KB boundary, and if it does, you will need to split the data into two separate commands. Aligning data As mentioned above, char sets and PM Graphics need to aligned on 1KB boundary. In Neon, the document data starts at $4000, so it is already aligned on a 1KB/4KB boundary. So if you define char sets and PM Graphics first, they will be aligned on a 1KB boundary. However, this isn't always possible, so you can use the %OF attribute of the :DATA (or :LOAD) command to align your data on a 1KB boundary. Here is a short example of using %OF to align on a 1KB boundary ; Example of using %of to align data on 1KB boundary :head :data #id d1 ;small image FF AA 55 00 FF AA 55 00 :data #id c1 $fs "H1:MLPfont.fnt" %sz 400 %of 3F8 ;align char set on 1KB boundary :page #ch c1 ;set CHBASE to databank c1 :text EXAMPLE OF ALIGNING ON 1KB BOUNDARY :fill Note in this example we needed an offset on 3FB (1016) to align the data statement on a 1KB boundary.
  13. I will try to update the documentation this weekend. I noticed some typos in it, which is never good in programming documentation. I will also try to expand it. I covered a lot of topics in the actual ADF Atari Documents on the disk, but need to provide them on the PC, so you don't have to read it in an emulator.
  14. Here is an example of how to create and call DLIs with CODE and CALL. The first DLI changes playfield 2 color, the second DLI changes playfield 2 color and flips the characters upside down. ;Here is an example of using :CODE to create a DLI ;And using :CALL to call the DLI :head :code #id c1 #ws 1 #c6 d4 ;each DLI has an #ID,sync changes to beginning of line #ws, set color 6 to d4 :code #id c2 #ws 1 #c6 44 #cm 4 ;#ID,sync, set color 6 to 44, set char mode to 4 :page :text Here is our default color :fill #mb 58 ;add blank lines until line 0x58 :call #id c1 ;call first DLI (c1), changing color :text Here is our new color :fill #mb 98 ;add blank lines :call #id c2 ;call second DLI (c2), changing color & flipping characters :text A third color and flipped characters :fill
×
×
  • Create New...