jacobus

thanks for the responses! Sounds like I was starting with the wrong code. Can anyone recommend an assembly routine that would do the following: -Copy small sequences of data (<64 bytes) from one location to another -Run in the VBI -Compatible with the TASM cross assembler version 3.2 -Fast and light thank you!

Thank you - much appreciated! Progress! It now simply hangs the computer instead of crashing Altirra! 🙂 I think I forgot to mention that this needs to run in the VBI. Does that change anything?

I assume this is eye-rollingly simple, but I'll ask anyway ... I'm trying to modify a general purpose copy routine to use three parameters - a source location, a destination location and the number of bytes to copy. Can someone please have a look at the attached code and tell me what I am doing wrong? ; ; Ullrich von Bassewitz, 2003-08-20 ; Performance increase (about 20%) by ; Christian Krueger, 2009-09-13 ; ; void* __fastcall__ memcpy (void* dest, const void* src, size_t n); ; ; NOTE: This function contains entry points for memmove, which will resort ; to memcpy for an upwards copy. Don't change this module without looking ; at memmove! ; ; .export _memcpy, memcpy_upwards, memcpy_getparams ; .import popax, popptr1 ; .importzp sp, ptr1, ptr2, ptr3 ; ---------------------------------------------------------------------- ;; ;; compiler directives ;; .lsfirst ;; ;; TASM Macros and Defines ;; #define lo(work) (work & $00FF) #define hi(work) ((work & $FF00) >> 8) #define bitprefix .byte $2C zplocation .equ $CC ;; Uses memory locations starting at this address. Make sure they are not in use by the system or your program. org .equ $4C00 ;; Start of main code sp .equ zplocation+$0 ;; Source pointer ptr1 .equ zplocation+$2 ;; Source ptr2 .equ zplocation+$4 ;; Destination ptr3 .equ zplocation+$6 ;; Size popax .equ $BA ;; popptr1 .equ $BB ;; ;; program_start ;; ;; .org org _memcpy jsr memcpy_getparams .export _memcpy memcpy_upwards ; assert Y = 0 ldx ptr3+1 ; Get high byte of n beq L2 ; Jump if zero L1 ; Unrolled to make it faster... lda (ptr1),Y ; copy a byte sta (ptr2),Y iny lda (ptr1),Y ; copy a byte sta (ptr2),Y iny bne L1 inc ptr1+1 inc ptr2+1 dex ; Next 256 byte block bne L1 ; Repeat if any ; the following section could be 10% faster if we were able to copy ; back to front - unfortunately we are forced to copy strict from ; low to high since this function is also used for ; memmove and blocks could be overlapping! ; { L2 ; assert Y = 0 ldx ptr3 ; Get the low byte of n beq done ; something to copy L3 lda (ptr1),Y ; copy a byte sta (ptr2),Y iny dex bne L3 ; } done jmp popax ; Pop ptr and return as result .export memcpy_upwards ; ---------------------------------------------------------------------- ; Get the parameters from stack as follows: ; ; size --> ptr3 ; src --> ptr1 ; dest --> ptr2 ; First argument (dest) will remain on stack and is returned in a/x! memcpy_getparams ; IMPORTANT! Function has to leave with Y=0! sta ptr3 stx ptr3+1 ; save n to ptr3 jsr popptr1 ; save src to ptr1 ; save dest to ptr2 iny ; Y=0 guaranteed by popptr1, we need '1' here... ; (direct stack access is three cycles faster ; (total cycle count with return)) lda (sp),y tax stx ptr2+1 ; save high byte of ptr2 dey ; Y = 0 lda (sp),y ; Get ptr2 low sta ptr2 rts .export memcpy_getparams .end thank you! Copy.A65

Welcome back Fred! In case you hadn't guessed it, I'm Jim from the HBO 🙂

Sorry, OT - Sorry OT, but you wouldn't be the Fred who is famous for his elevator repair skills, would you?

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!

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.

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? Copy.A65

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.atr So 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!

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.

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 🙂

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.

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.