damosan

I'd run a memory test in a loop for a bit. This gives the machine time to warm up as you're looking for hot chips. I had a 130XE that had ram issues in the high bank. Running Star Raiders was ok - loading stuff that required more than 64k would introduce weirdness - screen artifacts, locks, etc. I wrote a cc65 program to scan the bank - as time progressed it identified more and more bad bits. Some would lock high...some low. I had the memory replaced and everything was good.

Search this website - there are a lot of cc65 examples,links, helpful posts, etc. If you know C you'll be able to pick it up pretty quick.

You *could* do that on the computers - but you didn't have to. Instead you'd setup DLIs for the areas of the screen you were interested in and be done with it. The vertical blanks gave you more than enough time (generally) to do the painting you needed to do. I'm currently messing with a CC65/CA65 program to do this with soft sprites in graphics mode 8. Even with my mediocre understanding of assembly language I'm easily able to do 30 frames per second moving 7 sprites and 20 projectiles... The sprites are only 8x8 and the projectiles a single pixel but I've got room to do more. Writing 2600 kernels is much more involved.

Instructions? Yes. Techniques? Not really. On the 2600 you're writing code to paint the screen line by line and you have limited sprite support. The "regular" computers provide a richer environment - you have access to more players and missiles, you can do bitmap or character soft sprites, etc.

I got it down to 58 jiffies with this. paint_row: ;; ;; get row offset ;; lda yindexhi,y ; get row address sta ld+2 ; write high byte to LD/WR so we... sta wr+2 ; ...can use an absolute version. lda yindexlo,y sta ld+1 ; ditto... sta wr+1 ;; ;; init column to 0 ;; ldx #0 paint_col: ;; ;; plot pixel ;; ldy byteoffset256_table,x ; (4) get byte offset (4 - 35) ld: lda $ffff,y ; (4) ora bitmask_table,x ; (4) OR it with pixel bitmask wr: sta $ffff,y ; (5) ;; ;; increment column ;; inx ; (2) increment X bne paint_col ; (2) if we increment $ff it wraps to $00 so...

It's possible though it's kind of a PITA to embed assembly directly into C code - it's very easy, of course, to create separate assembly routines and let the linker figure it out.

yb is a zp byte. The lookup tables are page aligned. How would you rewrite the above to use X and Y based on Y being required the way it is?

Nothing in particular - just seeing how fast I can paint a screen with pixels painting one per pass (vs doing 8 pixels at a time by copying 0xff). The general use routine above is slower than this code. This can probably be made faster by increment argument by 40 after the first load. ;;; _speedtest ;;; ;;; at present this will paint a 255x192 Gr.8 screen at 777 pixels ;;; per jiffy (46.6k per second). ;;; ;;; runtime = 63 jiffies ;;; _speedtest: lda #0 sta yb paint_row: ;; ;; get row offset ;; ldy yb lda yindexhi,y ; get row address sta argument+1 ; argument = memory to write to lda yindexlo,y sta argument ;; ;; init column to 0 ;; ldx #0 paint_col: ;; ;; plot pixel ;; ldy byteoffset256_table,x ; (4/5) get byte offset (4 - 35) lda (argument),y ; (5/6) load screen byte ora bitmask_table,x ; (4/5) OR it with pixel bitmask sta (argument),y ; (6) store it back to screen byte ;; ;; increment column ;; inx ; (2) increment X bne paint_col ; (2) if we increment $ff it wraps to $00 so... end_of_cols: ;; ;; increment row ;; lda yb cmp #191 beq end_of_rows inc yb jmp paint_row end_of_rows: rts

As an aside I'm pushing 17k pixels per second - though I'm limiting it to 255x192 so I can push bytes. I modified the config file to put the buffers into page aligned memory. I'm going to mess around with the ZP loads.

Using cc65 I believe I'd have to edit the config file to create a number of special 0xff byte segments - then define the tables to reside in these segments. Then it should be possible to do a 2 byte vs. 3 byte lookup?

See attached code below. I'm calling this from a C program - it uses graphics mode 8 but only plots 256x192 so I can use bytes. YB, XB, and ARGUMENT are zero page. yindexhi, yindexlo, byteoffset256_table and bitmask_table are lookups. It works pretty well plotting 49k pixels in about 106 jiffies. I can replace the JSR/RTS with two JMPs (saving about 6 cycles per pixel - a little less if I do a jump indirect back to the caller). I've been staring at this for a while so I might be overlooking something short of inlining this. Thanks. ;;; ;;; _plot_pixel_256 should be called the first time we plot on a ;;; new row. As long as we're plotting on the same row we can ;;; call _plot_pixel_256_fast as the only item that changes is the ;;; column. ;;; _plot_pixel_256: ldy yb ; load row lda yindexhi,y ; get row address sta argument+1 ; argument = memory to write to lda yindexlo,y sta argument _plot_pixel_256_fast: ; call this if we're writing to same row ldx xb ; load column ldy byteoffset256_table,x ; get byte offset (4 - 35) lda (argument),y ; load screen byte eor bitmask_table,x ; xor it with pixel bitmask sta (argument),y ; store it back to screen byte rts

Such as this? https://icomp.de/shop-icomp/en/shop/product/Flickerfixer_Scandoubler.html

Hello - I recently got a pretty nice 1200 which I upgraded with a 030 card. It's a smoking little rig. I need pointers on graphics upgrades for this machine so I can do away with the flickering high res - I'm using a scart to HD upscaler. Thank you. D.

I know. They were coding for the general case trying to be conservative with memory consumption, etc. It's all a balancing act of course. We also know it's relatively easy to outperform the LINEA routines across the board if you cache line indexes, etc.

When did they start working on the ST? It was released mid 1985 so probably sometime in 1984? The 68k was released in '79 so I suspect lack of experience with the silicon wasn't a major factor. The end result is the natural consequence of having multiple teams just banging away on their stuff without any overarching architectural software direction. When they came together they then had to go through an exercise in trimming duplicate code/features to fit the memory budget. Some of the foundational code in the bios can be easily outperformed with hobbyist level assembler skills (LINEA anyone?). I'm sure they were working from the general case though e.g. "Get something that works good enough...we have other stuff to do!" There's a blog out there from someone who was on the ST team - the story sort of reinforces the above - it's an interesting read from the perspective of Atari History *AND* quick turn around product development and the trade offs that have to be made during the process.

As an aside... When you start to study the Atari ST system routines it *really* gives you the impression they mashed a bunch of stuff together under a very tight deadline. Which is exactly what they did. The outcome was a pretty good machine that kept Atari going for a few more years.

Morning All, I'm working on something in CA65 (assembler that comes with cc65) - I need a native debugger that I can run on the Atari that stays out of the way until a BRK instruction is encountered. Normally I'd use an emulator but I'm interfacing with a bit of hardware so I need something on the Atari. Any suggestions?

This yours? Please hurry with this.

That would be fun to work on actually. A top/down Ultima style display but with 1000 people stomping through the world. Having it be server based also makes the client a lot easier in that you don't have to worry about coding a story into the client - the server manages the story. It would also be kind of cool to have a bank of 8bits acting as a clustered server to drive it though a Python script on a Linux or Windows machine would probably do just as well. Mmmmm...that'd be slick. As an aside I was working on a Post-Apocalypse Ultima clone two years ago - I got the basics done but stopped working on it. I had planned to target the 130XE so I could store gobs of data and code additional gameplay stuff - as well as a very generic API to support loadable content moving forward (which would be easy to do with CC65 and banking/overlay support). Anyway...back to the Fuji...

Yeah - the work I'm doing is for everything else OTHER than SDX (hopefully). I've done some reading on how SDX does things you can expect relocatable code and loading into high memory instead of the dynamic MEMLO hack that is going on right now.

Relocator update... It's successfully checking for a device on boot. The ultimate goal with this is to have a covers-all-non-sparta-dos environments but we'll see once I get more of the driver in there and test with other DOS environments. Right now the driver is taking 631 bytes of RAM but 500 bytes of that are set asides for input/output buffers (if needed - can be reduced/removed). I plan to implement the rest of the CIO funcs this weekend. At present I show the new MEMLO once relocation is complete, the number of instruction fixes performed, and finally the number of bytes reclaimed after the assembly INIT function is called. I'm running DOS 2.5.

That's the magic right there.... I'll be updating the code to take it back to double buffering and repost.

For common services the URIs/URLs are all basically the same (HTTP, FTP, HTTPS, etc.). We can do the same for TCP and UDP. Instead of "N:TCP:3000" we can do "N:TCP:localhost:3000" which is what people typically do anyway. As far as traditional TCP/UDP comms what doesn't fit into that standard 4-part string?

strtok() is not your friend. It's a man, living in a van down by the river, promising candy to everyone who walks by. sscanf() is also not your friend but it's more like that uncle you only see at Christmas e.g. try sscanf( path, "N%c:%s:%s:%s", bucket, protocol, path, port ) For this stage though it'll be fine - the final product will want a real tokenizer for this. Also I'd suggest that all protocols follow the same format? N:HTTP://sss:p N:TCP://sss:p N:UDP://sss:p It's strange but make parsing easier (and safer) and it's ok if we deviate a bit (for the TCP/UDP).

I'm generally of the opinion that one should try to build their tools first...before downloading binaries. Public binaries tend to lag behind the development tree quite a bit. No. The code already uses pre-shifted bitmaps. The basic rule of "don't compute when you can pre-compute" applies here. Tweaking the PM setup stuff is easy but doesn't really gain much at the end of the day. The part that needs work is that main game loop. Converting it back to double buffering with two display lists would take about 15 minutes (basically call _graphics( 7 + 16 ) twice storing relevant pointers). I'd be interested in a true double buffering GR.7 config using EOR to update the bitmaps on each screen. That'd be useful and remove the flickering - probably getting at least 30fps if not more with no flickering. Trying to figure that part out hurt my head so the flickering version got posted.