jacobus
-
Posts
781 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by jacobus
-
-
Sorry, OT -
9 hours ago, Fred Toronto said:Hello folks... just recently resurrected my Atari 800 and was looking to display video output from it in a window on my Windows laptop.
Sorry OT, but you wouldn't be the Fred who is famous for his elevator repair skills, would you?
-
14 hours ago, Gemintronic said:
A half arsed barely explained rambling:
Maybe several techniques combined?
* Fully custom meta tile chunks (i.e. hand placed tiles as a stamp) - First quest cave entrance, Castle sections, etc..
* Procedurally generated meta tile chunks (i.e. prng placed tiles over background tiles in a stamp) - Grassy plains, Desert, Ocean
* Procedural meta tile chunks with custom accent tiles overlayed (i.e. hand placed tiles + prng placed tiles over background tiles in a stamp) - Grassy plains with dead tree, Desert with oasis, Shoreline with ocean
I say stamp as in instead of storing each tile in the world individually use, say, 16x16 chunks that have their own hand designed tile layouts.
I say use a pseudo random number generator to make sure the "randomly" placed accent tiles are always in the same place given the world x/y coordinates.
I'm thinking of strategies used in games like Daggerfall, Oblivion, The Faery Tale Adventure, etc..
I think Fort Apocalypse uses a similar technique when it expands the tiles into the playfield - the landscape is always slightly different.
A static map has appeal as that it would not take any extra code in the game itself to draw/maintain - additionally I envisioned a game where the player could wander back and forth over the landscape without it changing. However the idea of saving some effort in creating static maps is appealing. I'll look at ways to create some random or pseudo random effects.
Of course, I don't want the landscape to be too static - the player must be able to have some impact on the environment (killing monsters, opening doors, etc). I had considered saving each tile as it scrolled out of sight. That would really slow things down! ?
thanks everyone for your feedback!
-
1
-
-
14 hours ago, popmilo said:
I would say you've started in a right direction, and I wouldn't rule out disk load from time to time...
Games like Zelda were coded with abstractions similar to yours just applied over more levels.
Something like:
- "Base tiles" 2x2 chars (wood, grass, stone, bricks, roads etc).
- "Large tiles" 4x4 base tiles (8x8 chars) (Tree, part of house, edge of mountain, river etc...).
- Part of level close to screen size made from 4x4 "large tiles" (forest, clearing, rocky area, desert etc... (total of 32x32 chars size))
If you look at something like original NES rpg games there are those screen sized rooms, caves, dungeons where only difference is which wall has a door or which enemies are inside... One room like that was probably just couple bytes in mem.So base tiles could be 256x4 = 1 Kb
large tiles = 256x16 = 4Kb
large "parts" = 256x16 = 4Kb
And finally map could be = 64x64 = 4Kb-----------------------------------------------------
Total: 13Kb for map of 2048x2048 chars... Thats 50x80 screens
Play with sizes a little and whole map size can explode to what ever you want
And all this without touching something like RLE compression of same tiles in a row...
On speed of draw I would say best solution is to "draw only parts that change". There are methods like nes does with same principle possible on Atari too.
Reserve 2 or 4 times size of screen and then "just" change display list pointers and draw "new stuff" that comes into screen.
Interesting. However, I struggled with keeping track of identically sized tiles on my program, the idea of different sizes is rather daunting. Certainly something to consider.
-
On 6/11/2020 at 6:01 PM, Irgendwer said:
Thanks for the link! I played with the code a bit but and made it compatible with the TASM Assembler, I'm a bit lost on how to pass the three parameters to it (sourcemem,destmem,length). Can you please help?
-
On 6/11/2020 at 5:38 PM, Philsan said:
@jacobus, I've just tested your ATR on PAL Atari 800XL with AVGCart.
It runs smooth, a little less smooth than Altirra with disk acceleration turned on.
Excellent! Thanks for testing that!
-
Several times this winter I watched my youngest playing the latest of the Legend of Zelda games on the Nintendo Switch. I was impressed with the huge open world that the game provided. Room for many different environments and terrains and all accessible (more or less) at once. Seeing a game like that always makes me wonder about implementing it on the Atari.
How would I create the largest possible scrolling playfield on a standard Atari?
The largest playfield I’ve been able to create so far has been the one in Imp – which is 48 chars high by 128 wide (it could be 256 wide without the fog of war). So the max size (with enough memory left over for everything else) would be around 12,288 (Antic mode 4) characters. Each level takes about 5K of disk space. I could cram 6 to 8 levels on a disk. Not bad. Except I wanted more.
So, using tiles was the obvious answer – I could define tiles of 8 x 8 characters and build the playfield from that. I could create a map and represent the placement of each tile with a single byte. However, there was still a limit to what I could store in memory. Definitions for 128 tiles would take 8K, 256 tiles would consume 16K. And then they would have to be stored in memory for display. Still not providing the extra-large playfield I really wanted.
Then I hit upon the idea of a dynamic scrolling system – the screen would scroll a bit then load new tiles from disk and then continue scrolling. For better performance, I would keep the entire map in RAM and load each tile as needed. The scrolling algorithm would be kind of fun – I’d have to detect that the player had reached the boundary, load in new data and then change the display (basically scroll back) to reuse the same memory that had already been traveled. And make it smooth and seamless. In all 8 directions!
At that point I decided to shelve the project.
Recently however, I decided to have a go at writing this – something keep me sane during a series of excruciatingly boring Zoom meetings. (SAP implementation)
ExploreDiskWIP.atrSo here is my first stab at a solution. Besides the executable, there are two important files on the disk – the first called 0Tiles.txt is the tile definitions (I currently only have about 20). Although each tile only consumes 64 bytes, I have stored one per sector. This simplifies the lookup code and also allows the rest of the space to be used as metadata to describe the tile. The other file 1Map.txt describes how to map those tiles into the playfield. The program loads the entire map into RAM (currently 4K). Multiple maps could exist on the disk providing a number of discrete levels as well. Or (memory permitting) an even larger map could be created!
So, with these parameters, I get a playfield that is 64 tiles wide by 64 tiles high. Each tile is 8 x 8 characters. A total of 512 x 512 or 262,144 total characters! All smooth scrolling in 8 directions. That’s more like it!
You’re probably wondering about performance. A very good question. Within Altirra, with the disk acceleration turned on, the tiles load quickly enough that there is no noticeable delay. On a real Atari loading from a disk drive, each load involves a noticeable pause – bad but not lethal. I also tried a MaxFlash cart and was disappointed that it was not perfectly smooth – however it was better than the diskette. I’d be interested to learn how the program performs on other hardware.
The playfield does have some flicker – I won’t get rid of that until I move my redraw routine into the VBI and right now Quick is having no part of that. I’ll need to figure out how to write a fast memory copy routine in assembler.
Of course, nothing is quite that easy. Now that I have the ability to display a huge playfield, I’ll have to populate it. Which will require me to create both a tile editor and a map editor. More fun!
-
6
-
-
On 5/18/2020 at 11:48 AM, jacobus said:
16K, CTIA, tin contacts, OS A.
Embossed numbers are 1 80 2378, printed label is 180 1278 - not sure why the embossed and printer numbers come close but don't match.
Does anyone know if the 16K 800's (like the above) shipped with 1 x 16K board or 2 x 8K? Also, any idea when Atari stopped using tin contacts and switched to gold?
-
One for me please.
-
4 hours ago, Allan said:
Hopefully you will consider archiving this.
If not, please let me know - I have the complete set (AP/GL/AR). However my AR is still in the shrink wrap, so that one is not available. Not sure who owned my set, but not good news for a company to never need the AR portion of their accounting system ?
-
2
-
1
-
1
-
-
24 minutes ago, Stephen said:
Holy shit-balls. Is that for real? That's the ugliest thing I have ever seen. Please don't tell me that turd just sat on top of the membrane kb underneath?
It is rather nasty looking. ? And no, don't worry - it replaces the membrane keyboard altogether. Interestingly, I think the maroon key-tops are an option - the one I have is a slightly less hideous grey. Also note the "Tara" on the inverse key. Mr Fish pointed out, Inhome avoided using the Atari logo on their keyboard as well.
-
2
-
-
16K, CTIA, tin contacts, OS A.
Embossed numbers are 1 80 2378, printed label is 180 1278 - not sure why the embossed and printer numbers come close but don't match.
-
2
-
-
I just sent (via PayPal) $100 Canadian. Not so much in real dollars but hopefully enough to help
Take care José - Keep well!
-
41 minutes ago, Wrathchild said:
Best to clarify here that it means a 1 Megabyte (8 Megabit) cartridge which has two 29f040 chips, each 512 Kilobytes, with a 64 Kilobyte erasable block size. So (512 / 64) = 8 blocks per chip
The 128 Kilobyte (1 Megabit) cartridge has one 29f010 chip with a 16 Kilobyte erasable block size. So 128 / 16 = 8 blocks.
Yes absolutely! And please let me note that my code has only ever been used on a 8mbit cartridge. Not sure how or if it will work on the 1mb version.
-
I've attached some MaxFlash code originally written by Steve Tucker designed to be called from Quick programs. In order to save some calls I modified it a bit, but the reading and writing still work the same. Please keep in mind that the examples below are at a fairly high level - you can drill down into the code to see what actually makes the cartridge work.
To write:
NewSetSector(Sector#) - choose the sector to act upon
NewEraseSect(Sector#) - must be done before writing *
NewWrite(CartPage#,RAMPage#,NumPages#)
To read:
NewSetSector(Sector#) - choose the sector to act upon
NewRead(CartPage#,RAMPage#,NumPages#)
Because of the nature of Quick (the cartridge memory area and Quick's variable table are both located at $B000) a few accommodations needed to be made. Since Quick can't access the cartridge directly, it calls the MaxFlash code - which, when reading, moves the required pages from the cartridge to the specified RAM location, or when writing does the opposite.
* Once a sector is erased, any page on that sector can be written - once. The only way to re-write a page, is to first erase the sector it resides on.
The code uses the A, X and Y registers to pass parameters.
Note: With a 1mb cartridge, sectors are 64K blocks numbering between 0 and 15
I hope this is somewhat useful!
-
1
-
1
-
-
Unfortunately Air Support was never released (by Synapse) as a separate package. It was bundled with Quasimodo and only received a sticker on the outside of the box.
The artist (Tim Boxell) who did almost all of the Synapse art (everything except for Encounter) was here at AA a few years ago. He mentioned one cover that he created for an unreleased game, but I believe that title was Reptilian.
I think your mock-up looks great!
-
1
-
-
Good morning!
I wanted to let everyone know that I still have copies of the Cartridge and Disk versions available. Please let me know if you are interested in purchasing one.
thank you!
P.S. If you have already purchased a copy and would like a digital edition, please let me know - I can send it via PM here.
-
2
-
1
-
-
5 hours ago, CharlieChaplin said:
Hmmm, @jacobus
your signature reads "Completed: ... (several games), Imp, ..."
When did you complete Imp and errm, did you upload a newer version here at AA ? The latest copy I could find was from March 7, 2016 and this was just the playable demo. Or was the full version only available on disk / cart. from you ?!?
And what happened to "Cranston's Farm" ?!? Was it released anywhere for download ?!?
Hi Andreas
I think I got a little carried away when I added those two to the "completed" section. Imp is done in that the program is done, but I am still (yes - after several years) still working on the levels. I have a few weeks over the holidays - I'll try to give it some attention! Cranston's Farm is another matter - I thought it was all good and then I showed a copy to StefanD. He pointed out a few dozen major issues and shook his head sadly. I'm not sure if I should scrap this one entirely or gut it and start over. Another complicating factor is after watching my youngest play the latest Zelda game (on the switch), I am inspired to try to create a very very large open world type game. I think I can do this with a 1mb cartridge and a version of the Imp engine. Will be very interesting to try!
Anyways, thanks for the nudge - I will revisit it soon!
-
12
-
-
First batch of cartridges and disk orders sent!
-
3
-
-
14 hours ago, doctor_x said:
interested in the cart version but I need to wait until after Christmas... Not sure if I should wait to contact you or use this as my contact and just have you delay me?
I'll put one aside for you - please PM when you're ready to order
-
6 minutes ago, ndary said:
Interested in the cart version.. How.do i order?
Hi Nir
Please send me a PM with your address and which version(s) you want to order.
regards
-
It’s finally here! Dungeon Hunt II Game of the Year Edition is ready for ordering!
The new version of Dungeon Hunt includes the following features:
- 24 levels – (4 new more than the ABBUC version)
- Improved pliability and game balancing
- 15 different monsters
- Multiple weapons – melee and ranged
- Magical attacks
- Ladders that link upper and lower levels – 3D dungeons!
- New Sneak mode to bypass difficult enemies
- Up to 80 monsters per level
And more!
- Separate autosave for each level
- Automatic PAL/NTSC compatibility
- Cartridge version will save directly to the cart
Requirements:
An Atari home computer with joystick. The Disk version requires 48K and a compatible disk drive, the Cartridge version requires 64K.
Ordering Information:
There will be two versions of the package – prices include shipping to Canada, USA and (most of) Europe.
Disk version $40.00 USD
Cartridge version $62.00 USDI have a dozen copies of the disk version ready to ship now, more disks are on order. The cartridge version will start shipping in approximately 1 week – as soon as my shipment of AtariMax carts arrives.
To order, please send me a PM detailing your order and shipping address and I will provide a PayPal address.
(Package includes: shrink wrapped box, full colour manual, diskette or cartridge, custom feelie, letter - Disk version shown)
Thank you!
P.S. I’m looking for the Page Six package from Synapse. If anyone has an extra one, please contact me – perhaps we can make a deal! ?-
6
-
1
-
Quick update!
First off, thank you everyone for your interest! I really appreciate the support!
Good news, I have been able to add game saving directly to the cartridge so the hybrid approach I had mentioned earlier is out the window (where it belongs :-)). With this development, I've gone ahead and ordered a large batch of cartridges - they should arrive soon. With those and the arrival of the feelies I should be able to start assembling and shipping packages very soon. I will create a new thread with order information in the next few days.
Thanks to the tireless testing and feedback efforts of StefanD the new version will have all the enhancements I mentioned and a much improved player experience.
-
3
-
-
I'm here!
I ran a BBS called the "Scran Locker" for a few years in the mid eighties. Was also a long time member of the HBO.
-
Is it a trick of the light or are those tin (as opposed to gold) connectors?
-
1
-
And all this without touching something like RLE compression of same tiles in a row...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Video capture Atari 800 to Windows 10 laptop
in Atari 8-Bit Computers
Posted
Welcome back Fred! In case you hadn't guessed it, I'm Jim from the HBO ?